System and Method for Conveying Information

ABSTRACT

A system and method for conveying data include the capability to determine whether a transaction request credit has been received at a computer module, the transaction request credit indicating that at least a portion of a transaction request message may be sent. The system and method also include the capability to determine, of a transaction request message is to be sent, whether at least a portion of the transaction request message may be sent and to send the at least a portion of the transaction request message if it may be sent.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.12/264,871 now U.S. Pat. No. 7,873,741, which is a divisionalapplication of U.S. application Ser. No. 10/310,400, now U.S. Pat. No.7,447,794.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to computer systems, and, moreparticularly, to a system and method for conveying information.

BACKGROUND OF THE INVENTION

As computers have become more and more powerful, they have acquired theability to process more and more data. Furthermore, because they canprocess more and more data, computers need to be able to exchange datawith other computers rapidly in order that they may operate efficiently.Moreover, computers that exchange data with each other often need to beable to determine the status of each other in order that they canexchange data properly and efficiently.

SUMMARY OF THE INVENTION

According to the present invention, a system and method for conveyinginformation is provided. In particular embodiments; the system andmethod provide the ability to exchange processor input/output data andnon-processor data and to execute atomic memory operations.

In certain embodiments, a method for conveying information includesdetermining whether a transaction request credit has been received at acomputer module, the transaction request credit indicating that at leasta portion of a transaction request message may be sent. The method alsoincludes determining, if a transaction request message is to be sent,whether at least a portion of the transaction request message may besent and sending the at least a portion of the transaction requestmessage if it may be sent.

In particular embodiments, a method for conveying information includesdetermining, at a computer module, whether at least a portion of atransaction request message may be received. The method also includessending, if at least a portion of a transaction request message may bereceived, a transaction request credit, the transaction request creditindicating that at least a portion of a transaction request message maybe sent, and receiving a transaction request message.

The present invention has a variety of technical features. For example,in some embodiments, transaction request messages are only sent to acomputer module after the computer module has indicated that it hasavailable memory. Thus, transaction request messages should rarely, ifever, overflow. As another example, in certain embodiments, transactionresponse messages are only sent to a computer module after the computermodule has indicated that it has available memory. Thus, transactionresponse messages should rarely, if ever, overflow. As an additionalexample, in particular embodiments, error correction codes associatedwith data may allow for the identification of single-bit, double-bit,and multi-bit errors, which provides improved protection against errors.Moreover, the error correction codes may allow for the correction ofsome errors. As a further example, in certain embodiments, cached readsof data may be performed, and the requesting computer module may beinformed when the data is no longer valid.

Of course, some embodiments may possess none, one, some, or all of thesetechnical features and/or additional technical features. Other technicalfeatures will be readily apparent to those skilled in the art from thefollowing figures, written description, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings described below provide a more complete understanding ofthe present invention and its technical features, especially whenconsidered in light of the following detailed written description:

FIG. 1 illustrates one embodiment of a system for conveying data inaccordance with the present invention;

FIG. 2 illustrates a signaling diagram for conveying data in the systemof FIG. 1;

FIG. 3 illustrates another signaling diagram for conveying data in thesystem of FIG. 1;

FIG. 4 illustrates a message for conveying data in accordance with oneembodiment of the present invention;

FIG. 5 illustrates another message for conveying data;

FIG. 6 illustrates yet another message for conveying data;

FIG. 7 is a flowchart illustrating a method for conveying data inaccordance with one embodiment of the present invention; and

FIG. 8 is a flowchart illustrating a method for conveying data inaccordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates one embodiment of a system 10 for conveyinginformation in accordance with the present invention. In general, system10 includes a host computer module 20 and a remote computer module 30,which each typically include a memory and a processor. In addition,system 10 includes a signal transport device 40 coupled between hostcomputer module 20 and remote computer module 30. Signal transportdevice 40 is responsible for conveying information between host computermodule 20 and remote computer module 30. Information may includecomputer module status data, graphics data, general data, computermodule commands, and/or any other appropriate type of computer moduleinformation.

In more detail, host computer module 20 includes a memory 21, a creditgenerator 26, and a credit counter 28. Memory 21 stores data regardingthe status of host computer module 20, data to be conveyed to remotecomputer module 30, messages from remote computer module 30, themessages containing graphics data, commands, and/or status data for hostcomputer module 20, and/or any other appropriate type of information. Toaccomplish this, memory 21 includes a status data portion 22, a dataportion 23, a transaction request message buffer portion 24, and atransaction response message buffer portion 25. In other embodiments,however, memory 21 may have any number and/or arrangement of portions.Memory 22 may include read-only memory (ROM), random-access memory(RAM), compact-disc read-only memory (CD-ROM), registers, and/or anyother type of electromagnetic or optical volatile or non-volatileinformation storage device. Credit generator 26, which will be discussedin more detail below, is responsible for informing remote computermodule 30 when host computer module 20 is able to receive at least aportion of a certain type of message from remote computer module 30.Credit counter 28, in contrast, which will also be discussed in moredetail below, is responsible for tracking how many of at least a portionof a certain type of message may be sent from host computer module 20 toremote computer module 30. Credit generator 26 and credit counter 28 maybe implemented by logic encoded in a computer readable medium, anapplication-specific integrated circuit (ASIC), a field programmablegate array (FPGA), or any other appropriate type of software orhardware. Host computer module 20 may include any appropriate type ofprocessor for accessing and/or coordinating the functions of memory 21,credit counter 26, and credit generator 28.

Remote computer module 30, in turn, includes a memory 31, a creditcounter 36, and a credit generator 38. Memory 31 stores data regardingthe status of remote computer module 30, data to be conveyed to hostcomputer module 20, messages from host computer module 20, the messagescontaining graphics data, commands, and/or status data for remotecomputer module 30, and/or any other appropriate type of information. Toaccomplish this, memory 31 includes a status data portion 32, a dataportion 33, a transaction request message buffer portion 34, and atransaction response message buffer portion 35. In other embodiments,however, memory 31 may have any number and/or arrangement of portions.Memory 31 may include ROM, RAM, CD-ROM, registers, and/or any otherappropriate type of electromagnetic or optical volatile or non-volatileinformation storage device. Credit counter 36, to be discussed in moredetail below, is responsible for tracking how many of at least a portionof a certain type of message may be sent from remote computer module 30to host computer module 20. Credit generator 38, in contrast, also to bediscussed in more detail below, is responsible for informing hostcomputer module 20 when remote computer module 30 is able to receive atleast a portion of a certain type of message from host computer module20. Credit counter 36 and credit generator 38 may be implemented inlogic encoded in a computer-readable medium, an ASIC, an FPGA, or anyother appropriate type of software or hardware. Remote computer module30 may include any appropriate type of processor for accessing and/orcoordinating the functions of memory 31, credit counter 36, and creditgenerator 38.

In particular embodiments, remote computer module 30 may be a CoretalkModule and host computer module 20 may be an SGI™ Host Computer Module.In certain embodiments, signal transport device 40 allows remotecomputer module 30 to directly communicate with SGI™ computer systemsthat support the SGI™ NUMAlink™ network cabling system. In someembodiments, host computer module 20 may maintain memory coherencybetween the SGI™ computer system and remote computer module 30 andconverts between the NUMAlink™ protocol, which is used in the SGI™computer system, and the protocol used on signal transport device 40.

As mentioned previously, signal transport device 40 allows for theexchange of messages, which may contain status data, data, commands,and/or any other appropriate type of information, between host computermodule 20 and remote computer module 30. In the illustrated embodiment,signal transport device 40 is a bus that includes 179 links, denoted by41-65. In other embodiments, however, signal transport device 40 mayhave any number of links or may be any other appropriate type of devicefor conveying information. Links 41-65 may be wires, lines, pins,cables, and/or any other type of electrical conductors including the useof wireless or optical medium.

Link set 41 includes sixty-four links for conveying information fromhost computer module 20 to remote computer module 30. Thus, link set 41is physically 64-bits wide. In other embodiments, however, link set 41may have any appropriate width. In particular embodiments, link set 41supports conveying information a double data rate (DDR). Thus, asillustrated, link set 41 may allow 128-bits of information to beconveyed during each period of the channel clock, one transfer occurringduring the rising edge of the channel clock and the other transferoccurring during the falling edge of the channel clock. Link set 53 issimilar to link set 41 except that it conveys information from remotecomputer module 30 to remote computer module 20.

The transfer of information between host computer module 20 and remotecomputer module 30 is timed by a signal on channel clock link 51. Inother embodiments, however, the signals may be timed in any of a varietyof other manners. As illustrated, link 51 conveys a channel clock signalfrom host computer module 20 to remote computer module 30. The channelclock signal may allow remote computer module 30 to operate in aphase-locked manner with host computer module 20. In particularembodiments, the channel clock signal is a 400 MHz differential signalsourced by host computer module 20.

Link set 42 is responsible for conveying clock signals associated withthe information transferred on link set 41. These clock signals allowhost computer module 20 and remote computer module 30 to maintain skewacross the 64-bit information signals on link set. In embodiments whereinformation is conveyed on link set 41 according to DDR, clock signalsare also sent on link set 42 according to DDR. In particularembodiments, the first clock signal is associated with the first eightinformation links, the second clock signal is associated with the secondeight information links, the third clock signal is associated with thethird eight information links, the fourth clock signal is associatedwith the fourth eight information links, the fifth clock signal isassociated with the fifth eight group of information links, the sixthclock signal is associated with the sixth eight information links, theseventh clock signal is associated with the seventh eight informationlinks, and the eighth clock signal is associated with the eighth eightinformation links. Link set 54 is responsible for conveying similarsignals for the information transferred on link set 53.

Link set 43 is responsible for conveying Error Correction Code (ECC)signals associated with the information conveyed by link set 41. Ingeneral, an ECC may be used to detect, report, and/or correct single-biterrors, double-bit errors, and/or multi-bit errors. In certainembodiments, to be discussed in more detail below, remote computermodule 30 may uses the signals conveyed by link set 43 to detect andcorrect single-bit errors, detect and report double-bit errors, anddetect and report at least some multiple-bit errors. In embodimentswhere information is transferred using DDR, the signals on links set 43are also sent according to DDR, resulting in sixteen ECC signals beingsent during each period in the illustrated embodiment. Link set 55 isresponsible for conveying similar signals for the informationtransferred on link set 53.

Link 44 is responsible for conveying clock signals for the ECC signalsconveyed on link set 43. Host computer module 20 and remote computermodule 30 use the signals conveyed over link 44 to maintain skew acrossthe signals conveyed over link set 43. In embodiments where signals areconveyed over link set 43 according to DDR, clock signals are also senton link 44 according to DDR. Link 56 is responsible for conveyingsimilar signals for the signals conveyed over link set 55.

Link 45 and link 46 are responsible for conveying signals that indicatethe beginning and end of messages conveyed by link set 41. To accomplishthis, link 45 conveys a signal indicating the beginning of a messagebeing sent over link set 41, and link 46 conveys a signal indicating theend of a message being sent over link set 41. The signals sent over link45 and link 46 are single data rate (SDR) signals. Thus, the signals aretransmitted once during a clock period. In particular embodiments, whena signal is asserted on link 45, the signals on link set 41 containinformation regarding the type of message being conveyed, destinationaddresses, data enable bits, and/or information. Furthermore, when thesignal is asserted on link 46, the information on link set 41 containsthe last portion of a message. Link 57 and link 58 convey similarsignals for messages being conveyed over link set 53.

Link 47 conveys signals that indicate an error has occurred between hostcomputer module 20 and remote computer module 30. Remote computer module30 uses the signal conveyed over link 47 to indicate whether an errorwas detected in a message transferring on link set 41. Link 59 conveys asimilar signal from remote computer module 30 to host computer module 20for signals on link set 53.

Link 48 is responsible for conveying a signal indicating that themessage being conveyed over link set 41 is a transaction request.Typically, a transaction request is the initiating message for a bustransaction, which will be discussed in more detail below. Host computermodule 20 uses the signal on link 48 to indicate that link set 41, link45, link 46, and link 47 are conveying valid information for atransaction request. In particular embodiments, a complete transactionrequest should be conveyed over signal transport device 40 beforeanother transaction request will be conveyed; however, individualportions of a transaction request may be interleaved among portions of atransaction response, to be discussed in more detail below. Thus, hostcomputer module 20 may use link 48 to indicate that a portion of atransaction request is being conveyed. Link 60 is responsible forconveying a similar signal from remote computer module 30 to hostcomputer module 20.

Link 49 is responsible for conveying a signal indicating that atransaction response message is being sent from host computer module 20to remote computer module 30. Typically, a transaction response messageis the concluding message for a bus transaction, which will be discussedin more detail below. Host computer module 20 uses link 49 to indicatethat link set 41, link 45, link 46, and link 47 contain validinformation for a transaction response message. In particularembodiments, a response message should transfer over these links beforeanother transaction response will be conveyed; however, portions of atransaction response message may be interleaved among portions of atransaction request message. Thus, host computer module 20 may use link49 to indicate that a portion of a transaction response is beingconveyed. Link 61 is responsible for conveying a similar signal fromhost computer module 30 to host computer module 20.

Link 50 is responsible for conveying a signal regarding transactionrequest credits from remote computer module 30 to host computer module20. In general, a credit is an indication that a first computer moduleprovides to a second computer module to indicate that the first computermodule has room for at least a portion of a certain type of message. Inthe illustrated embodiment, remote computer module 30 uses the requestcredit signal to inform host computer module 20 that remote computermodule 30 has room in transaction request buffer 34 for at least aportion of a certain type of transaction request message from hostcomputer module 20. Credit generator 38 of remote computer module 30 isresponsible for initiating this signal, and host computer module 20maintains a count of the transaction request credits received withcredit counter 28. If the request credit count is zero and remotecomputer module 30 de-asserts the signal on link 50, host computermodule 20 does not transmit another transaction request, or a portionthereof, until remote computer module 30 asserts the signal on link 50again. In particular embodiments, the signal indicates that a completetransaction request message may be conveyed.

Link 62 conveys a similar signal, which is initiated by credit generator26, from host computer module 20 to remote computer module 30. Remotecomputer module 30 maintains a count of the transaction request creditsreceived from host computer module 20 using credit counter 36. If thetransaction request credit count is zero and host computer module 20de-asserts the signal on link 62, remote computer module 30 does notsend another transaction request message, or a portion thereof, untilhost computer module 20 asserts the transaction request credit signalagain. In particular embodiments, the signal indicates that hostcomputer module 20 has room for 128-bits of a transaction requestmessage in transaction request buffer 24.

Link 52 is responsible for conveying a control clock signal from hostcomputer module 20 to remote computer module 30. Remote computer module30 uses the control clock signal to maintain skew across thecorresponding control signals, such as, for example, 45, 46, 47, 48, 49,62, and 63. Link 64 conveys a similar signal from remote computer module30 to host computer module 20. Host computer module 20 uses the controlclock signal to maintain skew across the corresponding control signals,such as, for example, 57, 58, 59, 60, 61, and 50.

Link 63 is responsible for conveying a signal regarding transactionresponse credits from host computer module 20 to host computer module30. Host computer module 20 uses the response credit signal to informremote computer module 30 that host computer module 20 has room intransaction response buffer 25 for at least a portion of a certain typeof transaction response message from remote computer module 30. Creditgenerator 26 of host computer module 20 is responsible for initiatingthis signal, and remote computer module 30 maintains a count of thetransaction response credits received with credit counter 36. If theresponse credit count is zero and host computer module 20 de-asserts thesignal on link 63, remote computer module 30 does not transmit anothertransaction response message, or a portion thereof, until host computermodule 20 asserts the signal on link 63 again. In particularembodiments, the signal indicates that host computer module 20 has roomfor 128-bits of a transaction request message in transaction responsebuffer 25.

Link 65 is responsible for conveying a reset signal from host computermodule 20 to remote computer module 30. When host computer module 20asserts the reset signal, remote computer module 30 enters a reset stateand reinitializes its internal logic.

As alluded to previously, the protocol for information conveyance onsignal transport device 40 is based on message passing. Accordingly,host computer module 20 and remote computer module 30 may use messagesto convey information between each other, which is one type of bustransaction. Bus transactions may include reads of information, writesof information, atomic memory operations (AMOs), invalidate-cacheflushes, and/or any other appropriate type of operation involvingcomputer modules. In particular embodiments, messages may be used toperform six types of bus transactions—reads of data, writes of data,fetch atomic memory operations (AMOs), stores AMOs, graphics writes, andinvalidate cache-flushes. Table 1 lists the six types of bustransactions and the types of messages for each transaction for certainembodiments.

TABLE 1 Bus Transaction Requests Responses Reads Read Request MessageRead Response Message Writes Write Request Message Write ResponseMessage Fetch AMOs Fetch AMO Request Message Fetch AMO Response MessageStore AMOs Store AMO Request Message Store AMO Response Message GraphicsGraphics Write Request Graphics Write Credit or Writes Message GraphicsWrite Error Response Message Invalidate- Invalidate-Cache Flush NotApplicable Cache Flushes Request Message

In general, a message can be of any size. In particular embodiments,however, messages are sent in 128-bit increments—the amount ofinformation that may be transferred across a link set of signaltransport device 40 in one period using DDR, each link conveying atwo-bit part of the portion. Furthermore, in certain embodiments, fourmessage sizes are used. In these embodiments, message sizes are basedupon a flow control unit (FLIT), each FLIT corresponding to a 128-bittransfer. The messages may be one FLIT, two FLITs, nine FLITs, or tenFLITs in size. The message size used may vary depending on differenttypes of bus transactions and for requests/responses,

A timing diagram for sending a one-FLIT message in these embodiments isillustrated by FIG. 2. As illustrated therein, channel clock signal 151is the signal conveyed on link 51, request valid signal 148 is thesignal conveyed on link 48, response valid signal 149 is the signalconveyed on link 49, head signal 145 is the signal conveyed on link 45,tail signal 146 is the signal conveyed on link 46, error signal 147 isthe signal conveyed on link 47, information signals 141 are the signalsconveyed on link set 41, information group clock signals 142 are thesignals conveyed on link set 42, ECC signals 143 are the signalsconveyed on link set 43, and ECC clock signal 144 is the signal conveyedon link 44. Accordingly, a message is being sent from host computermodule 20 to remote computer module 30. Furthermore, the message is atransaction response message because response valid signal 149 isasserted. Note that response valid signal 149 is only asserted for oneperiod because the message is one-FLIT in length, meaning that it willbe conveyed in one period. Moreover, because only a one-FLIT message isbeing sent, head signal 145 and tail signal 146 are asserted, becausethe 128-bits of information represented by information signals 141 arethe beginning and end of the message.

FIG. 3 illustrates a two-FLIT message that is being sent from remotecomputer module 30 to host computer module 20. Thus, channel clocksignal 151 is the signal conveyed on link 51, request valid signal 160is the signal conveyed on link 60, response valid signal 161 is thesignal conveyed on link 161, head signal 157 is the signal conveyed onlink 57, tail signal 158 is the signal conveyed on link 58, error signal159 is the signal conveyed on link 159, information signals 153 are thesignals conveyed on link set 53, information group clock signals 154 arethe signals conveyed on link set 54, FCC signals are the signalsconveyed on link set 155, and ECC clock signal 156 is the signalconveyed on link 56. Request valid signal 160 is asserted to indicatethat the message is a transaction request. Note that signal 160 isasserted for two periods because a two-FLIT message transfers betweenthe computer modules in two periods. Furthermore, head signal 157 isasserted during the first period of the transfer to indicate that theinformation conveyed on link set 53 during this period is the firstportion of the message, and tail signal 158 is asserted during thesecond period of the transfer to indicate that the information conveyedon link set 53 during this period is the last portion of the message.

Similar signal timings are used for the nine-FLIT messages and theten-FLIT messages. For example, for a nine-FLIT message, the requestvalid or response valid signal would be asserted for nine periods toindicate that the message is a request or a response, respectively, thehead signal would be asserted during the first period to indicate thatinformation conveyed on the information link set is the first portion ofthe message, and the tail signal would be asserted during the ninthperiod to indicate that the information conveyed on the information linkset is the last portion of the message. Additionally, information wouldbe transferred on the appropriate information link set for nine periods.Furthermore, information group clock signals would be conveyed on theappropriate information group clock link set for nine clock periods, ECCsignals would be conveyed on the appropriate link set for nine periods,and the ECC clock signal would be sent on the appropriate link for nineperiods.

As just discussed, messages can be conveyed in portions over signaltransport device 40. In particular embodiments, each portion, or FLIT,corresponds to the amount of information that can be conveyed in oneperiod. For the illustrated embodiment of signal transport device 40,therefore, each FLIT could contain 128-bits, the amount of informationthat can be sent over one of link set 41 or link set 53 at a DDR.

Each FLIT may be classified as a message head, message body, or messagetail. Every message has a message head. Additionally, every message hasa message tail, although in some cases, the message tail is the same asthe message head. When the head signal is asserted on signal transportdevice 40 and the request valid or response valid signal is asserted, itindicates that the FLIT being conveyed on one of link set 41 or link set53 is the first FLIT, or head, of a message. When the tail signal isasserted on the signal transport device and the request valid orresponse valid signal is asserted, it indicates that the FLIT beingconveyed on one of link set 41 or link set 53 is the last FLIT, or tail,of the message. When, however, both the head signal and the tail signalare not asserted on the signal transport device and the request validsignal or the response valid signal is asserted, it indicates that theFLIT being conveyed on one of link set 41 or link set 43 is a middleFLIT, or message body, of a message. Thus, only messages longer than twoFLITs have message bodies.

As mentioned previously, in particular embodiments, for each directionof signal transport device 40, a new transaction request message cannotbe sent over the signal transport device until all of the FLITs for theprevious transaction request have transferred over the signal transportdevice. Likewise, a transaction response cannot be sent over the signaltransport device until all the FLITs of the previous transactionresponse have transferred over the signal transport device. However,individual FLITs of a transaction request and a transaction response canbe interleaved on the signal transport device. For example, if atransaction request was being sent over signal transport device 40, thetransaction request valid signal would be asserted while the transactionrequest message was being sent over the signal transport device. Then,however, before the entire transaction request message was conveyed overthe signal transport device, the transaction response valid signal wouldbe asserted, indicating that a transaction response message was beingsent over the signal transport device. When one or more FLITs of thetransaction response message had been sent, the request valid signalwould then again be asserted to signify that the transaction requestmessage was again being conveyed over the signal transport device.Additionally, the head signal would be asserted when the transactionrequest message originally began to be sent over the signal transportdevice and again when the transaction response message started to besent over the signal transport device. Furthermore, the tail signalwould be asserted when the transaction response message was finishedbeing conveyed over the signal transport device, and the tail signalwould be asserted when the transaction request message had completed itsconveyance over the signal transport device.

As mentioned previously, signal transport device 40 conveys messagesbetween host computer module 20 and remote computer module 30. Themessages may contain status data about a computer module, data from acomputer module, commands for a computer module to perform an action,such as send particular data back to the requesting computer module,and/or any other appropriate type of information. In general, messagingis accomplished with transaction request messages, which may containstatus data, data, and/or commands, and transaction response messages,which may contain status data and/or data. The messages may have anyappropriate form for conveying information between computer modules.

FIG. 4 illustrates a first FLIT 200 of a message for particularembodiments of the invention. Note that FLIT 200 may itself be themessage or may be the initial portion of a message. First FLIT 200contains a command word section 210 and a message head section 230. Asillustrated, command word section 210 occupies 32-bits of the FLIT, andmessage head 230 occupies 96-bits of the FLIT. In other embodiments,however, command word section 210 and message head section 230 mayoccupy any number of bits in the FLIT.

In more detail, command word section 210 contains fields that supplyidentification, error, and control information for the message. In theillustrated embodiment, these fields are the destination identification(ID) field 212, the sound ID field 214, the message type field 216, thetransaction number field 218, the data size field 220, the processorinput/output (PIO) transaction field 222, the error field 224, and theread type field 226. Furthermore, the destination ID field occupies2-bits, the source ID field 224 occupies 2-bits, the message type fieldoccupies 4-bits, the transaction number field occupies 8-bits, the datasize field occupies 2-bits, the PIO transaction field 222 occupies1-bit, the error field 224 occupies 1-bit, and the read type field 226occupies 2-bits of command word section 210. But in other embodiments,the fields may have varying sizes and/or arrangements in command wordsection 210. Note that not all of the space in command word section 210is used; this space may be reserved to allow for compatibility betweendifferent versions of system 10 and may contain zeros when not used.

Message type field 216 indicates the type of bus transaction with whichthe message is associated and whether the message is a request or aresponse for that transaction. Bus transactions may include reads ofdata, writes of data, atomic memory operations, invalidate-cacheflushes, and/or any other appropriate type of operation involvingcomputer modules. Table 2 illustrates the values that message type field216 may contain certain embodiments, along with the associated messagetypes.

TABLE 2 Bus Message Type Transaction [3:0] Message Type Reads 0000 ReadRequest 0001 Read Response Writes 0010 Write Request 0011 Write ResponseNot Applicable 0100 Reserved 0101 Reserved

Transaction number field 218 associates a transaction response messagewith its corresponding transaction request message. The computer modulethat creates the transaction request message places the transactionnumber in transaction number field 218 of the transaction requestpackage. When, and possibly if, the computer module that receives thetransaction request message creates a transaction response message, thecomputer module places the transaction number that was in the requestmessage into transaction number field 218 of the response message. Inthe illustrated embodiment, transaction number field 218 is actuallysplit between fields of command word section 210, the lower order bitsof the transaction number residing in transaction number field 218 a andthe higher order bits of the transaction number residing in the bits offield 218 b. For particular embodiments, messages used for read, write,fetch AMO, and store AMO bus transactions require a transaction number.Messages used for graphics write and invalidate-cache flush bustransactions, however, have the transaction numbers set to zero. Table 3illustrates the bus transactions that require transaction numbers forthese embodiments.

TABLE 3 Message Type Bus Transaction [3:0] Message Type TNUM Value Reads0000 Read Request Transaction Number 0001 Read Response TransactionNumber Writes 0010 Write Request Transaction Number 0011 Write ResponseTransaction Number Not Applicable 0100 Reserved Not applicable 0101Reserved Not applicable

The logic used to maintain transaction numbers in a computer module isimplementation specific. For example, a designer may choose to provideup to 255 outstanding requests, regardless of the type of bustransactions that are occurring, or a designer may choose to provide upto 255 outstanding requests for each type of bus transaction supportedby the computer modules.

PIO transaction field 222 indicates whether the bus transaction isassociated with the memory of a processor, such as, for example, aregister. For example, in particular embodiments, PIO transaction field222 is one bit in size, with a one indicating that the bus transactionis associated with processor memory. Thus, if remote computer module 30issues a read transaction request with the PIO transaction bit equal tozero, it indicates that remote computer module 30 is requesting a readof data stored in non-PIO memory, such as, for example, system memory.When, however, the PIO transaction bit is one, it indicates that the bustransaction is associated with PIO space. For instance, when hostcomputer module 20 issues a write request with the PIO transaction bitset to one, it indicates that host computer module 20 is requesting awrite of data into a register of remote computer module 30. Accordingly,in particular embodiments, the PIO transaction bit would be set to zerofor all non-PIO memory related transactions, including reads, writes,fetch AMOs, store AMOs, and invalidate-cache flush, but the PIOtransaction bit would be set to one for all PIO related transactions,including reads and writes. Furthermore, the PIO transaction bit couldbe set to one for graphics operations.

Read type field 226 is valid for memory read transaction requests andmemory read transaction responses. For other transactions, read typefield 226 could be set to zero. In particular embodiments, read typefield 226 contains two bits, and when message type field 216 is set to0000, indicating a read request message, and the PIO transaction bit isset to zero, indicating a non-processor memory transaction, read typefield 226 indicates the type of memory read requested. Table 4illustrates the type of memory reads for these embodiments. When,however, message type field 216 is set to 0001, indicating a readresponse message, and the PIO transaction bit is set to zero, indicatinga non-processor memory transaction, the read type field indicates thetype of memory read response. Table 5 illustrates the memory readresponses for the detailed embodiment.

TABLE 4 Read Read Type Request [1:0] Type Description 00 Get Read datafrom a memory location. The data is coherent at the time of the read.The HCM will not notify the RCM when the data is modified in systemmemory. 01 Reserved Reserved 10 Cached, Read data from memory location.The data is coherent not at the time of the read. When the data ismodified in timed system memory, the HCM performs an Invalidate- CacheFlush bus transaction to notify the RCM that the data is no longervalid. 11 Cached, Read data from a memory location. The data is timedcoherent at the time of the read. When the data is modified in systemmemory before a predetermined time-out value has expired, the HCMperforms an Invalidate-Cache Flush bus transaction to notify the RCMthat the data in the RCM is no longer valid. When the data is modifiedin system memory after a predetermined time-out value has expired, theHCM will not notify the RCM when the data is modified in system memoryand the RCM automatically invalidates the corresponding data stored inthe RCM.

TABLE 5 Read Read Type Response [1:0] Type Description 00 Non- The readdata in this read response message is valid specu- and may be used bythe RCM. lative 01 Reserved Reserved 10 Specu- The read data in thisread response message is lative speculative and should not be used bythe RCM until it receives either a speculative-acknowledge read-response message or a non-speculative read response message. Thespeculative-acknowledge read-response message indicates that the datarevived in a previous speculative-read-response message is valid and maybe used by the RCM. The non-speculative read response message indicatesthat the data received in a previous speculative-read-response messageis not valid and should be replaced by the data provided in the non-speculative read response message. 11 Specu- The read data received in aprevious speculative-read- lative response message is valid and may beused by the Acknowl- RCM. edge

Data size field 220 indicates the total number of bytes of data, suchas, for example, memory data, graphics data, or register data,associated with a bus transaction. In particular embodiments, data sizefield 220 is 2-bits in size and may be used to provide the indicationsdenoted in Table 6.

TABLE 6 Data Size Bytes of Data in Corresponding Request or Response[1:0] Transaction Message Sizes 00 8-bytes One-FLIT message or Two-FLITmessage 01 Reserved Not applicable 10 128-bytes Nine-FLIT message 11128-bytes Nine-FLIT message or Ten-FLIT message

Note that messages may also contain byte enable fields, which indicatewhich bytes in the 8-bytes or 128-bytes of data are valid. In general,the byte enable fields are not part of the command words, although theycould be, and will be discussed in more detail later.

For read transactions, data size field 220 in a transaction requestmessage indicates the amount of data to place in the transactionresponse message. There is, of course, typically no data in a readrequest message. For write transactions, however, data size field 220 ina transaction request message indicates the amount of data, such as, forexample, memory, graphics, or register, present in the transactionrequest message. The transaction response message may have the samevalue in data size field 220, but there is typically no data in thetransaction response message.

Source ID field 214 contains an identifier for the source of a message.In particular embodiments, the identifier is an identifier remotecomputer module 30 and matches the identification number of signaltransport device 40. Furthermore, the identifier is a two-bit valuestored in a programmable register in remote computer module 30. Fortransaction request and transaction response messages from remotecomputer module 30 to host computer module 20, remote computer module 30places the identifier in source ID field 214 of the message. Fortransaction request and transaction response messages from host computermodule 20 to remote computer module 30, source ID field 214 has nomeaning, and host computer module 20 sets source ID field 214 to zero.

Destination ID field 212 contains an identifier the destination of amessage. In particular embodiments, the identifier is an identifier forsignal transport device 40 and is a two-bit value. For transactionrequest messages from host computer module 20 to remote computer module30, host computer module 20 places the identifier in destination IDfield 212 of the message. For transaction response messages from hostcomputer module 20 to remote computer module 30, host computer module 20places the source ID from the transaction request message that itreceived from remote computer module 30 into destination ID field 212 ofthe response message that it sends back to remote computer module 30.For transaction request and transaction response messages from remotecomputer module 30 to host computer module 20, destination ID field 212has no meaning and is set to zero.

Error field 222 indicates whether an error occurred during theprocessing of a bus transaction. In particular embodiments, error field222 is one-bit in size and indicates whether or not an error occurredduring the processing of a transaction request message. Thus error field224 may only be valid for transaction response messages and may be zerofor transaction request messages. Examples of errors that would causethe error field 224 to indicate an error are: 1) a request to access amemory address that does not exist; 2) a request to write data into aread only register; and 3) a request to write more data into a registerthan the register can hold.

In general, messages contain different types and/or amounts of datadepending on the size and/or purpose of the message. Thus, for message200, there may be any number of formats for message head section 230. Incertain embodiments, however, message head section 230 message maycontain a byte enable information, a graphics credit, data, and/or anaddress. Of course, section 230 may also contain nothing.

FIG. 5 illustrates a one-FLIT message containing byte enableinformation, a graphics credit, and data. As discussed previously, themessage contains command word section 210, which may be configured asdiscussed previously. The message also contains a byte enable field 232,a graphics credit field 234, and data fields 236, which may containmemory, graphics, or register data, for example. For the illustratedembodiments, this type of message may be used for: 1) PIO 8-byte ReadResponse messages; 2) PIO Error Read Response messages; 3) Memory ReadError Response messages; and 4) Fetch AMO Response messages. Note,however, that not all of the fields may be used for each of the messagetypes. For example, PIO error Read Response messages and the Memory ReadError response message may not include data fields 236. The graphicscredit is used to manage graphics request flow from a higher level thanthe Request Credit 50 credits. Graphics credits are maintained at thesource of the graphics request messages, for example a processor, sorequests can flow without interruption from the source to the RCM. Inother words, the source knows how much room is available at thedestination which allows graphics requests to not be slowed by theflow-control of any intermediate interconnects.

Illustrated in FIG. 6, is a one-FLIT message containing an address. Aswith other messages, this message contains command word section 210 anda message head section 230. Message head section 230 includes byteenable field 232, graphics credit field 234, and an address field 238.In the illustrated embodiment, address field 238 is 56-bits in length,although it may be of any other size in other embodiments. For thisembodiment, this type of format may be used for: 1) PIO 8-byte ReadRequest messages; 2) PIO Full 128-byte Read Request messages; 3) Memory128-byte Read Request message; 4) Fetch AMO Request messages; and 5)Invalidate Cache Flush Request messages, although some fields may not beused in each of the message formats.

Another type of one-FLIT message that may be used contains byte enablefield 232 and graphics credit field 234 in message head section 230. Inthe illustrated embodiments, this type of one-FLIT message may be usedfor: 1) PIO 8-byte Write Response messages; 2) PIO Partial 128-byteWrite Response messages; 3) Memory 128-byte Write Response messages; 4)Store AMO Response messages; 5) Graphics Write Credit Response messages;6) Graphics Write Error Response messages; and 7) Memory 128-byteSpeculative-Acknowledge Response messages, although some fields may notbe used in each of the message formats.

A two-FLIT message, in contrast, contains a message head—the firstFLIT—and a message tail—the second FLIT. In particular embodiments, thismessage format may be used for transaction request messages that containup to 8-bytes of data that will be written to system memory, a graphicsdevice, or a register. As such, the first FLIT of the message may besimilar to the one FLIT message illustrated in FIG. 6, and the secondFLIT of the message may contain the data, typically in bits [63:0]. Thistype of message format may be used for: 1) PIO 8-byte Write Requestmessages; 2) Store AMO Request messages; and 3) Graphics 8-byte WriteRequest messages, although some fields are not used in some of themessage formats.

A nine-FLIT message contains a message head, seven body segments, and atail. This message format is commonly used for request and responsemessages that contain larger amounts of data. In particular embodiments,the message is used to convey up to 128-bytes of data. In general, thefirst FLIT of this type of message may be similar to the FLITillustrated by FIG. 6. The remaining FLITs of this message may containdata, from or for a memory, graphics, or a register. This type ofmessage format may be used for: 1) Graphics 128-byte Write Requestmessages, which may contain 16, 32, 64 or 128 bytes of valid data; 2)PIO Full 128-byte Read Response messages; 3) Memory Full 128-byte WriteRequest messages; 4) Memory Full 128-byte Read Response messages; and 5)Memory Full 128-byte Speculative-Read Response messages, although somefields may not be used in each of the messages.

A ten-FLIT message contains a message head, eight body segments, and amessage tail. This message format is commonly used for write requestmessages that contain larger amounts of data. In particular embodiments,the message up to convey up to 128 bytes of data. In general, the firstFLIT of the ten-FLIT message may be similar to the FLIT illustrated byFIG. 6, except for the fact that it may not have byte enable field 232.The second FLIT of the message may contain 128-bits of cache-line byteenables, to be discussed in more detail below, and the remaining eightFLITs of the message may contain up to 128-bytes of data. This type ofmessage format may be used Some bus transactions that may be implementedusing this type of message format include: 1) PIO Partial 128-byte WriteRequest messages, which may contain 1 to 128-bytes of valid data; and 2)Memory Partial 128-byte Write Request messages, which may contain 1 to128 bytes of valid data, although some fields are not used in each ofthe messages.

Byte enable field 232 facilitates using Big Endian mode or Little Endianmode, which are two common types of addressing modes with which computersystems reference data in memory. To accomplish this, byte enable field232 allows messages to indicate which bytes of the data portion of themessage contain valid data. For particular embodiments, byte enablefield 232 specifies which bytes of an 8-byte or a 128-byte data segment,which may be part of a PIO transaction or a memory transaction, arevalid. For one-FLIT or two-FLIT messages, the data may reside in an8-byte field that resides in bits [63:0] of a FLIT. Because of the fixeddata field size, the address used for these transactions should bealigned on 8-byte boundaries in memory, i.e., address bits [2:0] shouldbe equal to zero. Thus, an 8-bit byte enable field may indicate thevalidity of each of the 8-bytes of data, one bit being associated witheach of the 8-bytes. Thus, the byte enable field provides a means forsignal transport device 40 to support both Big Endian and Little Endianaddressing modes. For example, when byte address 0x1 contains valid datain Big Endian mode, the seventh byte enable bit is set. When, however,byte address 0x1 contains valid data in Little Endian mode, the secondbit of byte enable field 232 is set.

As mentioned previously, the byte enable field in a ten-FLIT message mayoccupy the entire second FLIT. This allows the specification of thevalidity of each byte in the remaining eight FLITS. For example, in theembodiments where each FLIT contains 128-bits, the data up to 128-bytesthat reside in the last eight FLITs of the message. Because of the datafield size, the address used for these transactions are aligned on128-byte boundaries in memory, i.e., address bits [6:0] should be equalto zero. The byte enable field in ten-FLIT messages would then be a128-bit field in the second FLIT of the message, with one bitcorresponding to each of the 128-bytes of data. Thus, the ten-FLIT byteenable field provides a means for signal transport device 40 to supportboth Big Endian and Little Endian addressing modes. For example, whenbyte address 0x1 contains valid data in Big Endian mode, byte enable bit126 is one, but when byte address 0x1 contains valid data in LittleEndian mode, byte enable bit 113 is one. Note that while the ordering ofbytes within a 128-bit data field FLIT is different depending on theaddressing mode, the first data field FLIT transferred always containsquad word zero, and the last data field FLIT transferred always containsquad word seven, regardless of the addressing mode.

In particular embodiments, when data is part of a Fetch AMO transactionor a Store AMO Transaction message, which will be discussed in moredetail below, the data field in the message is an 8-byte field. However,AMO transactions may perform operations on an 8-byte or a 4-byte operandvalue in memory, and although the data field may be a fixed 8-byte sizein a message, the address for AMO transactions may be aligned on 64-byteboundaries in memory, i.e., address bits [5:0] are not used for theaddress. In each 64-byte AMO space in memory, therefore, only 64-bit,bits [63:0], for example, contain the current operand value, and64-bits, bits [127:64], for example, contain the previous operand value.Thus, while the 8-byte data field in an AMO transaction message maycorrespond to the current AMO operand in memory, this 64-bit locationmay be used as one 64-bit operand or as two 32-bit operands. The byteenable field in an AMO transaction message, therefore, may enable anentire 64-bit double word in memory, or enable the upper-half orlower-half of the 64 bit double word in memory as illustrated by Table7. Byte enable values other than 0x0F, 0xF0, or 0xFF are not supportedand may result in an error.

TABLE 7 Byte Enable Bits [90:88] Valid Data in Message 000 Reserved -Not a valid Byte Enable value. 001 The least-significant 16 bytes ofdata are valid. 010 The least-significant 32 bytes of data are valid.011 The least-significant 64 bytes of data are valid. 100 All 128 bytesof data are valid. 101 Reserved - Not a valid Byte Enable value. 110Reserved - Not a valid Byte Enable value. 111 Reserved - Not a validByte Enable value.

The amount of data in a graphics transaction message may be similar tothe amount of data in a memory transaction or a PIO transaction.Accordingly, in particular embodiments, the data field in a graphicstransaction message may be an 8-bytes or 128-bytes. When the data is8-bytes, the message is typically a two-FLIT message, and the byteenable field in a two-FLIT graphics message performs the same functionas the byte enable field of a two-FLIT PIO transaction message or amemory transaction message, each bit of the 8-bit byte enable fieldindicating that a corresponding byte of data is valid. When, however,the data of a graphics transaction message is 128-bytes, the message istypically a nine-FLIT message, and the byte enable field of a nine-FLITmessage is not 128-bits that enables each of the 128-bytes, but 8-bitsthat indicate the number of valid bytes of the 128-bytes of graphicdata. For example, the byte enable field may indicate that the leastsignificant 16-bytes, 32-bytes, 64-bytes, or 128-bytes are valid.

Table 8 provides a summary of the transaction request messages andtransaction request responses used on signal transport device 40 forparticular embodiments. In other embodiments, fewer, more, and/or adifferent combination of message types may be used.

TABLE 8 Request Messages Response Messages Msg Read Data Msg Read DataName Typ PIO Typ Size Size Name Typ PIO Typ Size Size TNUM Memory Full0x0 0 00 10 One Memory Full 0x1 0 00 10 Nine Y 128-byte Read FLIT128-byte Read FLIT (Get) (Non- speculative) Memory Full 0x1 0 10 10 NineY 128-byte Read FLIT (Speculative) Memory Full 0x1 0 11 10 Nine Y128-byte Read FLIT (Speculative Acknowledge) Memory Full 0x0 0 10 10 OneMemory Full 0x1 0 00 10 Nine Y 128-byte Read FLIT 128-byte Read FLIT(Cache not (Non- timed) speculative) Memory Full 0x1 0 10 10 Nine Y128-byte Read FLIT (Speculative) Memory Full 0x1 0 11 10 One Y 128-byteRead FLIT (Speculative Acknowledge) Memory Full 0x0 0 11 10 One MemoryFull 0x1 0 00 10 Nine Y 128-byte Read FLIT 128-byte Read FLIT (Cachetimed) (Non- speculative) Memory Full 0x1 0 10 10 Nine Y 128-byte ReadFLIT (Speculative) Memory Full 0x1 0 11 10 Nine Y 128-byte Read FLIT(Speculative Acknowledge) PIO 8-byte 0x0 1 00 00 One PIO 8-byte PIO 0x11 00 00 One Y Read FLIT FLIT PIO Full 128- 0x0 1 00 10 One PIO Full 128-0x1 1 00 10 Nine Y byte Read FLIT byte Read FLIT Memory Full 0x2 0 00 10Nine Memory Full 0x3 0 00 10 One Y 128-byte FLIT 128-byte Write FLITWrite Partial 128- 0x2 0 00 11 Ten Partial 128-byte 0x3 0 00 11 One Ybyte Memory FLIT Memory Write FLIT Write PIO 8-byte 0x2 1 00 00 Two PIO8-byte Write 0x3 1 00 00 One Y Write FLIT FLIT PIO Partial 0x2 1 00 11Ten PIO Partial 128- 0x3 1 00 11 One Y 128-byte FLIT byte Write FLITWrite Fetch AMO 0x6 0 00 00 One Fetch AMO 0x7 0 00 00 One Y FLIT FLITStore AMO 0x8 0 00 00 Two Store AMO 0x9 0 00 00 One Y FLIT FLIT Graphics8- 0xA 1 00 00 Two Graphics Credit 0xB 1 00 xx One N byte Write FLIT orError FLIT Graphics Full 0xA 1 00 10 Nine Graphics Credit 0xB 1 00 xxOne N 128-byte FLIT or Error FLIT Write Graphics 0xA 1 00 11 NineGraphics Credit 0xB 1 00 xx One N Partial 128- FLIT or Error FLIT byteWrite Invalidate- 0xD 0 00 00 One Not applicable N Cache Flush FLIT

As mentioned previously, a bus transaction typically consists of arequest message and one or more response messages. In particularembodiments, there are six types of bus transactions: read, write, fetchAMO, store AMO, graphics write, and invalidate-cache flush. Only certaintypes of bus transactions, however, are valid depending upon whether thetransaction is requested by host computer module 20 for remote computermodule 30, requested by remote computer module 30 for host computermodule 20, or are requested by remote computer module 30 for anothercomputer module. Table 9 illustrates the transaction types and theirvalidity for transfer for these embodiments.

TABLE 9 Valid Transactions HCM RCM RCM to to to Type Bus Transaction RCMHCM RCM Reads PIO 8-Byte Read Yes Yes Yes PIO Full 128-Byte Read Yes YesYes Memory Full 128-Byte Read No Yes No Writes PIO 8-Byte Write Yes YesYes PIO Partial 128-Byte Write Yes Yes Yes Memory Partial 128-Byte WriteNo Yes No Memory Full 128-Byte Write No Yes No Fetch AMOs Fetch AMO NoYes No Store AMOs Store AMO No Yes No Graphics Writes Graphics 8-ByteWrite Yes No Yes Graphics Full 128-Byte Write Yes No Yes Invalidate-Invalidate-Cache Flush Yes No No Cache Flush

Read transactions consist of a request message that contains a readaddress and a response message that contains the read data. Inparticular embodiments, there are two types of read transactions—PIOreads and memory reads.

Host computer module 20 and remote computer module 30 may use PIO readtransactions to read data from processor memory, such as, for exampleregisters, or for peer-to-peer input/output transactions. In particularembodiments, PIO read transactions are valid only if data size field 220indicates 8-bytes or 128-bytes. Transaction request messages for PIOreads with data size field 220 set to a different value may result in aresponse message with an error bit equal to zero or a discard of therequest message.

For an 8-byte PIO read transaction, the transaction consists of a PIO8-byte Read Request message and a PIO 8-byte Read Response message withmatching transaction numbers. The PIO 8-byte Read Request message is aone-FLIT message. Valid portions of this message are command wordsection 210 and message head section 230. Command word section 220includes the fields illustrated in FIG. 4. Destination ID field 212 andsource ID field 214 contain identifiers depending on which computermodule is producing the read request, as discussed previously. Messagetype field is 0x0, which indicates the message is a read request, andtransaction number field 218 contains a valid transaction number for theread request. Data size field is 0x0, which indicates that the messageis a request for an 8-byte double word of register data. Additionally,PIO transaction field 222 is one, which indicates a PIO transaction, andthe error field 224 is zero, because errors should not be asserted forrequest messages. Message head section 230 includes byte enable field232 and address field 238. Byte enable field 232 contains a key thatallows the register access to occur; however, the byte enable value isnot returned in the PIO 8-byte Read Response message, and the requestingcomputer module should keep track of which bytes will be valid in theresponse message. Address field 238 contains the 56-bit address of theregister to be read. For this type of transaction, the address should bealigned on 8-byte boundaries.

The PIO 8-byte Read Response message is also a one-FLIT message. Validportions of this message are command word section 210 and message headsection 230. Command word section 210 includes the fields illustrated inFIG. 4. Destination ID field 212 and source ID field 214 containidentifiers depending on which computer module is producing the readresponse, as discussed previously. Message type field 216 is 0x1,indicating a read response. Transaction number field 218 contains thetransaction number that was used for the corresponding PIO 8-byte ReadRequest message. Data size field 220 is 0x0, indicating that the messagecontains an 8-byte double word of register data, and PIO transactionfield 222 is one, indicating that a PIO transaction is occurring. Errorfield 224 is valid and, if error an has occurred in the bus transaction,is one. Message head section 230 contains the 8-bytes of register datareside in the final 64-bits of the response message. The requestingcomputer module should keep track of which bytes of this data are validbased on the PIO 8-byte Read Request message that it originally created.

A PIO Full Cache-Line Read transaction is used to read data fromregisters of a computer module. For example, remote computer module 30may use this transaction to read data from the registers of anotherremote computer module. In the detailed embodiment, this transactionincludes the PIO Full 128-byte Read Request message and the PIO Full128-byte Read Response message with matching transaction numbers. Notethat remote computer module 30 may use a PIO Full Cache-Line Readtransaction to read up to 128-bytes of data from another remote computermodule.

The PIO Full 128-byte Read Request message is a one-FLIT message. Validportions of this message include command word section 210 and messagehead section 230. Command word section 210 includes the fieldsillustrated in FIG. 4. Destination ID field 212 and source ID 214 fieldcontain identifiers depending on which computer module is producing theread request, as discussed previously. Message type field 216 is 0x0,which indicates the message is a read request. Transaction number field218 contains a valid transaction number for the read request. Data sizefield 220 is 0x2, which indicates that the message is a request for afull 128-bytes of register data, and PIO transaction field 222 is one,which indicates a PIO transaction. Error field 224 is zero, because theerrors should not be asserted for request messages. Message head section230 includes address field 238, which contains the 56-bit address of theregister to be read. For this type of transaction, the address should bealigned on 128-byte boundaries, i.e., bits [6:0] should be zero.

The PIO Full 128-byte Read Response message, in contrast, is a nine-FLITmessage. Valid portions of this message include command word section 210of the first FLIT and the entirety of the remaining eight FLITs, whichcontain up to 128-bytes of register data. Command word section 210includes the fields illustrated in FIG. 4. Destination ID field 212 andsource ID 214 field contain identifiers depending on which computermodule is producing the read response, as discussed previously. Messagetype field 216 is 0x1, which indicates that the message is a readresponse, and transaction number field 218 contains the same transactionnumber that was used for the corresponding PIO Full 128-byte ReadRequest message. Furthermore, data size field 220 is 0x2, whichindicates that the message contains a full 128-bytes of register data,and PIO transaction field 220 is one, which indicates a PIO transaction.Error field 224 is valid and, if equal to one, indicates that an erroroccurred during the processing of the bus transaction. Note that if anerror has occurred, the PIO Full 128-byte Read Response message may be aone-FLIT message with the error field equal to one in command wordsection 210, and, thus, the requesting computer module may need to beable to process either size error message appropriately. The 128-bytesof register data reside in the body of the PIO Full 128-byte ReadResponse message, i.e., the last eight FLITS.

Memory read transactions are used to read data from non-processor memoryof another computer module. For example, remote computer module 30 mayuse such a transaction to read data from system memory of host computermodule 20. In particular embodiments, memory read transactions are validonly if data size field 220 of command word section 210 is 0x0,indicating 8-bytes, or 0x2, indicating a full 128-bytes. Transactionrequest messages for memory reads with data size field 220 set to adifferent value may result in a response message with error field 224set to one, or the request message being discarded.

Remote computer module 30 may use a Memory Full 128-Byte Readtransaction to read 128 bytes of data from non-processor memory. Thistransaction consists of a Memory Full 128-Byte Read Request message andone of three types of response messages with matching transactionnumbers: 1) a Memory Full 128-Byte Read Non-speculative Responsemessage; 2) a Memory Full 128-Byte Read Speculative Response message; or3) a Memory Full 128-Byte Read Speculative Acknowledge message.

The Memory Full 128-Byte Read Request message is a one-FLIT message.Valid portions of this message include command word section 210 andmessage head section 230. Command word field 210 includes the fieldillustrated in FIG. 4. Destination ID field 212 and source ID 214 fieldcontain identifiers depending on which computer module is producing theread request, as discussed previously. Message type field 216 is 0x0,indicating that the message is a read request, and transaction numberfield 218 contains a valid transaction number for the read request. Datasize field 220 is 0x2, indicating that the message is a request for afull 128-bytes of memory data, and PIO transaction field 222 is zero,indicating a non-processor memory transaction. Read type field 226indicates whether the read request is a Get (0x0), Cached, Not Timed(0x2), or Cached, Timed (0x3) read, which will be discussed in moredetail below. Error field 224 is zero, because errors should not beasserted for request messages. Message head section 230 includes addressfield 238, which indicates the 56-bit address of the memory location tobe read. For this type of transaction, the address should be aligned on128-byte boundaries, i.e., address bits [6:0] should be zero.

As mentioned previously, there are three types of response messages tothis read request. The first is the Memory Full 128-Byte ReadNon-speculative Response message, which contains 128-bytes of valid readdata. Only one such response message should be generated because itcompletes the read transaction. The second response message is theMemory Full 128-Byte Read Speculative Response message, which contains128-bytes of unverified read data. Multiple such message may begenerated because this type of response message does not complete theread transaction. A subsequent Memory Full 128-Byte Read Non-speculativeResponse message or a subsequent Memory Full 128-Byte Read SpeculativeAcknowledge message completes the read transaction. The third responsemessage is the Memory Full 128-Byte Read Speculative Acknowledgemessage, which contains no read data, but indicates that the read datain a previously received speculative response message is valid. Only onesuch response message should be generated because it completes the readtransaction.

The read response messages are one-FLIT messages or nine-FLIT messages.Valid portions in the 9-FLIT messages include command word section 210and the entirety of the following 8 FLITS, which contain the 128-bytesof memory data. Command word section 210 includes the sectionillustrated in FIG. 4. Destination ID field 212 and source ID 214 fieldcontain identifiers depending on which computer module is producing theread response, as discussed previously. Message type field is 0x1, whichindicates that the message is a read response, and transaction numberfield 218 contains the same transaction number that was used for thecorresponding read request message. Data size field 220 is 0x2, whichindicates that the message contains 128-bytes data, valid or unverified.PIO transaction field is zero, which indicates a non-processor memorytransaction. Read type field 226 indicates the type of read responsemessage—non-speculative (0x0) or speculative (0x2). Error field 224 isvalid and, if equal to one, indicates that an error occurred during theprocessing of the bus transaction. The remaining eight-FLITS of themessage include the 128-bytes of valid or unverified data. Note that ifan error occurs, the read response message may be either a one-FLITmessage or a nine-FLIT message that has error field 224 set to one incommand word section 210. The requesting computer module may need to beable to process either size of error message correctly. The one-FLITmessage is similar to the nine-FLIT message except for the fact that itdoes not contain the eight-FLITS of data and read type field 226 is 0x3,indicating a speculative acknowledgement. The data size for thespeculative acknowledge is 0x2 and is associated with 128-bytes of data.

A write transaction allows one computer module to send data to aparticular location in another computer module. A write transactiontypically consists of the data that is being sent from the initiatingcomputer module and the address to which the data is to be written. Aresponse message typically confirms that the write occurred or failed.In particular embodiments, there are two types of write transactions,PIO writes and memory writes.

Host computer module 20 and remote computer module 30 may use PIO writetransactions to write data into processor memory or to performpeer-to-peer input/output transactions. In particular embodiments, PIOwrite transactions are valid only if data size field 220 of command wordsection 210 is 0x0, indicating 8-bytes, or 0x3, indicating up to128-bytes. Requests for PIO writes with the data size field 220 set to adifferent value may result in a response message with error field 224set to one or the request message being discarded.

In these embodiments, host computer module 20 and remote computer module30 use a PIO 8-byte Write transaction to write up to 8-bytes of datainto a register. The transaction includes a PIO 8-Byte Write Requestmessage and a PIO 8-Byte Write Response message with matchingtransaction numbers.

The PIO 8-byte Write Request message is a two-FLIT message. Validportions of this message include command word section 210, message headsection 230, and a portion of the second FLIT, which contains the data.Command word section 210 includes the fields illustrated in FIG. 4.Destination ID field 212 and source ID field 214 contain identifiersdepending on which computer module is producing the write request, asdiscussed previously. Message type field 220 is 0x2, which indicatesthat the message is a write request, and transaction number field 218contains a valid transaction number for the write request. Data sizefield 220 is 0x0, which indicates that the message contains an 8-bytedouble word of register data, and PIO transaction field is one, whichindicates a PIO transaction. Error field 224 is zero, because errorshould not be asserted for request messages. Message head section 230includes byte enable field 232 and address field 238. Byte enable field232 indicates which bytes of the register data are valid, and addressfield 238 contains the 56-bit address of the register to which the datais to be written. For this type of transaction, the address should bealigned on 8-byte boundaries, i.e., address bytes [2:0] should be zero.

The write response message is a one-FLIT message. The valid portion ofthis message is command word section 210. Command word section 210includes the fields illustrated in FIG. 4. Destination ID field 212 andsource ID field 214 contain identifiers depending on which computermodule is producing the response, as discussed previously. Message typefield is 0x3, which indicates that the message is a write response, andtransaction number field 218 contains the same transaction number thatwas used for the corresponding PIO write request message. Data sizefield 220 is 0x0, which indicates that the request message contains8-bytes of register data, and PIO transaction field is one, whichindicates a PIO transaction. Error field 224 is valid and, if equal toone, indicates that an error occurred during the bus transaction.

For larger writes of data between computer modules, a PIO PartialCache-Line Write transaction may be used. In particular embodiments, upto 128-bytes of data may be written into the register of anothercomputer module. In these embodiments, this transaction consists of aPIO Partial 128-byte Write Request message and a PIO Partial 128-byteWrite Response message with matching transaction numbers.

The PIO Partial 128-byte Write Request message is a ten-FLIT message.Valid portions of this message are command word section 210, messagehead section 230, the byte enable field in the second FLIT, and the128-bytes of register data in the last eight FLITS. Command word section210 includes the fields illustrated in FIG. 4. Destination ID field 212and source ID field 214 contain identifiers depending on which computermodule is producing the write request, as discussed previously. Messagetype field 216 is 0x2, which indicates that the message is a writerequest, and transaction number field 218 contains a valid transactionnumber for the write request. Data size field 220 is 0x3, whichindicates the message contains up to 128-bytes of register data. PIOtransaction field is one, indicating a PIO transaction, and error field224 is zero, because errors should not be asserted for request messages.Message head section 230 includes address field 238, which contains a56-bit address for the register in which the data is to be written. Forthis type of transaction, the address should be aligned on 128-byteboundaries, i.e., address bits [6:0] should be zero. The second FLIT ofthe write request includes the 128-bit byte enable field, whichindicates which bytes of the register write data, contained in the thirdthrough tenth FLITS, are valid.

The write response message is a one-FLIT message. The valid portion ofthis message is command word section 210. Command word section 210contains the field illustrated in FIG. 4. Destination ID field 212 andsource ID field 214 contain identifiers depending on which computermodule is producing the write response, as discussed previously. Messagetype field 216 is 0x3, which indicates that the message is a writeresponse, and transaction number field 218 contains the same transactionnumber that was used for the corresponding write request message. Datasize field 220 is 0x3, which indicates that the request message containsup to 128-bytes of register data, and PIO transaction field 222 is one,which indicates a PIO transaction. Error field 224 is valid and, ifequal to one, indicates that an error occurred during the processing ofthe bus transaction.

A memory write transaction may be used to write data from one computermodule to the non-processor memory of another computer module. Thetransaction consists of a write request message and write responsemessage. In particular embodiments, memory write transactions are validonly if data size field 220 of command word section 210 is 0x2,indicating a full 128-bytes, or 0x3, indicating a partial 128-bytes.Transaction request messages for memory writes with the data size fieldset to a different value may result in a response message with errorfield 224 set to one or the write request message being discarded.

For writes of up to 128-bytes of data, the transaction consists of aPartial 128-byte Memory Write Request message and a Partial Memory128-byte Write Response message with matching transaction numbers. Incertain embodiments, remote computer module 30 uses this type of writetransaction to write up to 128-bytes of data into the system memory ofthe host computer module 20.

The Partial Memory 128-byte Write Request message is a ten-FLIT message.Valid portions of this message include command word section 210, messagehead section 230, the 128-bit byte enable field in the second FLIT, andthe data in the last eight FLITS. Command word section 210 includes thefields illustrated in FIG. 4. Destination ID field 212 and source IDfield 214 contain identifiers depending on which computer module isproducing the write request, as discussed previously. Message type field216 is 0x2, which indicates that the message is a write request, andtransaction number field 218 contains a valid transaction number for thewrite request. Data size field 220 is 0x3, which indicates that themessage contains a partial 128-bytes of write data. PIO transactionfield 222 is zero, which indicates a non-processor memory transaction,and error field 224 is zero, because errors should not be asserted forrequest messages. Message head section 230 includes address field 238,which contains the 56-bit address to which the data is to be written insystem memory. For this type of transaction, the address should bealigned on 128-byte boundaries, i.e., address bits [6:0] should be zero.The second FLIT of the write request message contains the 128-bit byteenable field, which indicates the bytes of the written data that arevalid. In certain embodiments, if all of the byte enable bits are one,or if all the byte enable bits are zero, error warning information islogged in the system, but error field 224 is not one in the responsemessage. The last eight FLITs contain the up to 128 bytes of data to bewritten.

The write response message is a one-FLIT message. The valid portion ofthis message is command word section 210. Command word section 210includes the fields illustrated in FIG. 4. Destination ID field 212 andsource ID field 214 contain identifiers depending on which computermodule is producing the write response, as discussed previously. Messagetype field is 0x3, which indicates that the message is a write response,and transaction number field 218 contains the same transaction numberthat was used for the corresponding write request message. Data sizefield 220 is 0x3, which indicates that the request message contained128-bytes of memory data. PIO transaction field 222 is zero, whichindicates a non-processor memory transaction, and error field 224 isvalid and, if equal to one, indicates that an error occurred during theprocessing of the bus transaction.

A Full Memory 128-byte Write transaction is used to write 128-bytes ofdata into the system memory of another computer module. In certainembodiments, remote computer module 30 uses this type of transaction towrite 128-bytes of data into the system memory of host computer module30. This transaction consists of a Memory Full 128-Byte Write Requestmessage and a Memory Full 128-Byte Write Response message with matchingtransaction numbers.

The write request message for this transaction is a nine-FLIT message.Valid portions of the message are the command word section 210, messagehead section 230, and the following 8 FLITS, which contain the 128-bytesof write data. Command word section 210 includes the fields illustratedin FIG. 4. Destination ID field 212 and source ID field 214 containidentifiers depending on which computer module is producing the writerequest, as discussed previously. Message type field 216 is 0x2, whichindicates that the message is a write request, transaction number field220 contains a valid transaction number for the write request, and datasize field 220 is 0x2, which indicates that the message contains a full128-bytes of write data. PIO transaction field 222 is zero, whichindicates a non-processor memory transaction, and error field 224 iszero, because error signals should not be asserted for request messagemessages. Message head section 230 includes address field 238, whichcontains the 56-bit address to which the data is to be written in systemmemory. For this type of transaction, the address should be aligned on128-byte boundaries. The remaining eight FLITS contain the 128-bytes ofdata.

The write response message for this transaction is a one-FLIT message.The valid portion of this message includes command word section 210.Command word section 210 includes the fields illustrated in FIG. 4.Destination ID field 212 and source ID field 214 contain identifiersdepending on which computer module is producing the write response, asdiscussed previously. Message type field is 0x3, which indicates thatthe message is a write response. Transaction number field 218 containsthe same transaction number that was used for the corresponding writerequest message. Data size field 220 is 0x2, which indicates that thewrite request message contains 128-bytes of memory data, and PIOtransaction field 222 is zero, which indicates a non-processor memorytransaction. Error field 224 is valid and, if equal to 1, indicates thatan error occurred during the processing of the bus transaction.

Another type of bus transaction that may be implemented using signaltransport device 40 is an atomic memory operation (AMO). In particularembodiments, two types of AMO transactions may be performed: 1) fetch,in which an indivisible read-modify-write operation may be performed ondata in memory; and 2) store, in which an indivisible read-merge-writeoperation is performed on data in memory. During a Fetch AMOtransaction, the requested computer module returns data read from memoryto the requesting computer module and modifies the data in memory byincrementing the value of the data, decrementing the value of the data,or clearing the value of the data. During a Store AMO transaction, therequested computer module reads data from memory, merges the data withdata from a store AMO request message, and writes the result back intomemory location in one indivisible operation.

In particular embodiments, remote computer module 30 uses a Fetch AMOtransaction and a Store AMO transaction to modify the data in thenon-processor memory of host computer module 30. The Fetch AMOtransaction consists of a Fetch AMO Request message and a Fetch AMOResponse message with matching transaction numbers.

The Fetch AMO Request message is a one-FLIT message. Valid portions ofthis message include command word section 210 and message head section230. Command word section 210 includes the fields illustrated in FIG. 4.Destination ID field 212 and source ID field 214 contain identifiersdepending on which computer module is producing the request message, asdiscussed previously. Message type field 216 is 0x6, which indicatesthat the message is a Fetch AMO Request message, and transaction numberfield 218 contains a valid transaction number for the request message.Data size field 220 is 0x0, which indicates that the message is arequest for 8-bytes data, and PIO transaction field 224 is zero, whichindicates a non-processor memory transaction. Requests for Fetch AMOtransactions with the data size field set to a value other than 0x0 mayresult in a response message with the error field set to one or therequest message being discarded. Read type field 226 is zero, because isnot used, and error field 224 is zero, because errors should not beasserted for request messages. Message head section 230 includes byteenable field 232 and address field 238. Byte enable field 232 enables anentire 64-bit double word in memory, or enables the upper half or lowerhalf of the 64-bit double word in memory, as discussed earlier. Table 10specifies the values of the byte enable field 232 for this type of AMOfor these embodiments. Values in byte enable field 232 other than thosein Table 10 may not be supported. The requesting computer module maykeep track of the value of byte enable field 232, because it may notreturned in the response message. Address field 238 specifies the 64-bitdouble word in memory where the Fetch AMO transaction will be performedand selects the type of Fetch AMO operation to perform. Bits [55:6] ofthe field point to a 64-byte-aligned location in memory. In thislocation, double word zero contains the current operand for a Fetch AMOtransaction and double word one contains the previous operand for aFetch AMO transaction (or double word one contains the current operandand double word zero contains the previous operand, depending uponwhether the addressing mode is Big Endian or Little Endian). Doublewords two through seven are not used and are not modified by AMOtransactions. Bits [5:3] of the field indicate the type of Fetch AMO toperform, as shown in Table 11.

TABLE 10 Byte Enable Value Description 0x0F The least-significant32-bits of the 64-bit memory location are enabled for the Fetch AMOtransaction. 0xF0 The most-significant 32-bits of the 64-bit memorylocation are enabled for the Fetch AMO transaction. 0xFF All 64-bits ofthe memory location are enabled for the Fetch AMO transaction.

TABLE 11 Address Bits [5:3] Fetch AMO Operation 000 Fetch old data withno additional operation to create new data. 001 Fetch old data andcreate new data by incrementing the value of the data. Write the newdata to memory. 010 Fetch old data and create new data by decrementingthe value of the data. Write the new data to memory. 011 Fetch old dataand clear the data in memory by writing zero to memory. 1xx Reserved -Bit 5 of the Address field should be zero. The data is not modified.

The Fetch AMO Response message is also a one-FLIT message. Validportions in this message are command word section 210 and message headsection 230. Command word section 210 includes the fields illustrated inFIG. 4. Destination ID field 212 and source ID field 214 containidentifiers depending on which computer module is producing the responsemessage, as discussed previously, Message type field 216 is 0x7, whichindicates that the message is a Fetch AMO Response, and transactionnumber field 218 contains the same transaction number that was used forthe corresponding request message. Data size field 220 is 0x0, whichindicates that the message contains an 8-byte double word of data. PIOtransaction field 222 is zero which indicates a non-processor memorytransaction, and read type field 226 is zero, because it is not used.Error field 224 is valid and, if equal to one, indicates that an erroroccurred during the processing of the bus transaction. Message headsection 230 includes data fields 236, which contain the 8-bytes of fetchdata for the response message. The requesting computer module shouldkeep track of which bytes of this data are valid based on the requestmessage that it originally created.

For the Store AMO transaction, the Store AMO Request message is atwo-FLIT message. Valid portions of this message are command wordsection 210, message head section 230, and the portion of the secondFLIT that contains the data. Command word section 210 contains thefields illustrated in FIG. 4. Destination ID field 212 and source IDfield 214 contain identifiers depending on which computer module isproducing the response message, as discussed previously. Message typefield 216 is 0x8, which indicates the message is a Store AMO Request,and transaction number field 218 contains a valid transaction number forthe request. Data size field 220 is 0x0, which indicates that themessage contains an 8-byte double word of data. PIO transaction field222 is zero, which indicates a non-processor memory transaction, andread type field 226 is zero, because it is not used. Error field 224 isalso zero, because errors should not be asserted for request messages.Message head section 230 includes byte enable field 232 and addressfield 238. Byte enable field 232 enables an entire 64-bit double word inmemory, or enables the upper-half or lower-half of the 64-bit doubleword in memory. Table 12 specifies the valid values for byte enablefield 232 for these embodiments; byte enable values other than those inTable 12 are not supported. Address field 238 contains the address ofthe 64-bit double word in memory where the store AMO will be performed.Bits [55:6] of the field point to a 64-byte-aligned location in memory.In this location, double word zero contains the current operand for aStore AMO transaction and double word one contains the previous operandfor a Store AMO transaction, or double word one contains the currentoperand and double word zero contains the previous operand, dependingupon whether the addressing mode is Big Endian or Little Endian. Doublewords two through seven are not used and are not modified by AMOtransactions. Bits [5:3] of the field indicate the type of Store AMO toperform, as illustrated in Table 13.

TABLE 12 Byte Enable Value Description 0x0F The least-significant32-bits of the 64-bit memory location are enabled for the Store AMOtransaction; therefore, bits [31:0] of the data field are valid in theStore AMO Request message. 0xF0 The most-significant 32-bits of the64-bit memory location are enabled for the Store AMO transaction;therefore, bits [63:32] of the data field are valid in the Store AMORequest message. 0xFF All 64-bits of the memory location are enabled forthe Store AMO transaction; therefore, bits [63:0] of the data field arevalid in the Store AMO Request message.

TABLE 13 Address Bits [5:3] Store AMO Operation 000 Directly store thedata from the request message into the memory location. 001 Add the datafrom the request message to the current value of the memory location andthen store the result into the memory location. 010 Subtract the datafrom the request message from the current value of the memory locationand then store the result into the memory location. 011 Perform alogical AND of the data from the request message and the current valueof the memory location and then store the result into the memorylocation. 100 Perform a logical OR of the data from the request messageand the current value of the memory location and then store the resultinto the memory location. 101 Reserved - Data is not modified. 110Reserved - Data is not modified. 111 Reserved - Data is not modified.

The response message is also a one-FLIT message. The valid portion ofthe response message is command word section 210. Command word section210 includes the fields illustrated in FIG. 4. Destination ID field 212and source ID field 214 contain identifiers depending on which computermodule is producing the response message, as discussed previously.Message type field 216 is 0x9, which indicates the message is a StoreAMO Response, and transaction number field 218 contains the sametransaction number that was used for the corresponding request message.Data size field 220 is 0x0, which indicates that the request messagecontained an 8-byte double word of data. PIO transaction field 222 iszero, indicating a non-processor memory transaction, and read type field226 is zero, because it is not used. Error field 224 is valid and, ifequal to one, indicates that an error occurred during the processing ofthe bus transaction.

Another type of data transfer that may be implemented using signaltransport device 40 is a Graphics Write transaction. Using the GraphicsWrite transaction, computer modules may send graphics data by adedicated, higher bandwidth method. In particular embodiments, GraphicsWrite transactions are used to send graphics data to remote computermodule 30. In addition, remote computer module 30 may use a GraphicsWrite transaction to send graphics data to another remote computermodule. Graphics Write transactions may or may not be ordered withrespect to PIO Read or Write transactions.

In general, Graphics Write transactions include Graphics Write Requestmessages and Graphics Write Response messages, although in the certainembodiments, individual Graphics Write Request messages do not requirean associated response message. In addition, Graphics Write Requestmessages are always accepted and will not be rejected with a noacknowledgement. Particular embodiments include Graphics 8-byte Writetransactions, Graphics Partial 128-byte Write transactions, and GraphicsFull. 128-byte Write transactions.

A Graphics 8-byte Write transaction includes a Graphics 8-byte WriteRequest message and, possibly, a Graphics Credit Response message or aGraphics Write Error Response message. Host computer module 20 may usethe Graphics 8-byte Write transaction to write up 8-bytes of graphicsdata to remote computer module 30, and remote computer module 30 may usethe transaction to write up to 8-bytes of graphics data to anotherremote computer module.

The Graphics 8-byte Write Request message contains two FLITS. Validportions of this message are command word section 210, message headsection 230, and the data portion of the second FLIT. Command wordsection 210 includes the fields illustrated in FIG. 4. Destination IDfield 212 and source ID field 214 contain identifiers depending on whichcomputer module is producing the request message, as discussedpreviously. Message type field 216 is 0xA, which indicates that themessage is a graphics write request, and transaction number field 218 iszero, because it is not used. Data size field 220 is 0x0, whichindicates that the message contains an 8-byte double word of data. PIOtransaction field 222 is one, indicating a PIO transaction, and errorfiled 224 is zero, because errors should not be asserted for requestmessages. Message head section 230 includes byte enable field 232 andaddress field 238. Byte enable field 232 indicates which bytes of thegraphics write data are valid. Address field 238 contains the addressfor the graphics data write. When host computer module 20 creates thewrite request message, the address may be derived from the address pinsof a processor. Bits [6:3] indicate the first quad word location for thegraphics write. Remote computer module 20 may or may not utilize thisaddress.

A possible response to the Graphics 8-byte Write Request message is aGraphics Credit Response message. This message contains one-FLIT, andthe valid portions are command word section 210 and message head section230. Command word section 210 includes the fields illustrated in FIG. 4.Destination ID field 212 and source ID field 214 contain identifiersdepending on which computer module is producing the response message, asdiscussed previously. Message type field 216 is 0xB, which indicatesthat the message is a Graphics Credit Response. Transaction number field218 is zero because it is not used, and data size field 220 is zerobecause it is not used. PIO transaction field 22 is one, indicating aPIO transaction, and error 224 is valid and, if equal to one, whichwould make the message a Graphics Write Error Response message,indicates an error occurred during the processing of the bus transactionand that the credits are invalid. Conditions that would cause an errorresponse include the remote computer module receiving more GraphicsWrite Request messages than there is available room for, or the remotecomputer module receiving a Graphics Write Request message with anaddress which is not supported. Additionally, read type field 226 is0x0, because it is not used. Message head section 230 includes graphicscredit field 234, which indicates the number of graphics creditsavailable to the requesting computer module, each credit equal to one64-bit double word of graphics data. The first FLIT of a graphicsrequest message does not need to count toward the graphics credit value,however.

To write more than 8-bytes of graphics data, a Graphics Partial 128-byteWrite transaction may be used. This transaction may consist of only aGraphics Partial 128-byte Write Request message, although an appropriateGraphics Credit Response message or Graphics Write Error Responsemessage may be used.

The Graphics Partial 128-byte Write Request message has nine FLITS, andcommand word section 210, message head section 230, and the entirety ofthe second through ninth FLITS are the valid portions. Command wordsection 210 includes the fields illustrated in FIG. 4. Destination IDfield 212 and source ID field 214 contain identifiers depending on whichcomputer module is producing the request message, as discussedpreviously. Message type field 216 is 0xA, which indicates the messageis a graphics write request, and data size field 220 is 0x3, whichindicates that the message contains a partial 128-bytes of graphicsdata. Transaction number field 218 is zero because transaction numbersare not used, and read type field 226 is zero because it is also notused. PIO transaction field 222 is one, which indicates a PIO orgraphics transaction, and error field 224 is zero because errors shouldnot be asserted for request messages. Message head section 230 includesbyte enable field 232 and address field 238. Byte enable field 232indicates the number of valid bytes in the second through ninth FLITS,as illustrated in Table 7. Note that if byte enable field 232 is 0x1,0x2, or 0x3, data size field 220 should be 0x3, to indicate a partial128-bytes of data. Address field 238 contains the address for thegraphics data write.

One possible response message is the Graphics Credit Response message.Such a message is one FLIT in size and has command word section 210 andmessage head section 230 as the valid portions. Command word section 210includes the fields illustrated in FIG. 4. Destination ID field 212 andsource ID field 214 contain identifiers depending on which computermodule is producing the request message, as discussed previously.Message type field 216 is 0xB, which indicates that the message is agraphics credit response. Transaction number field 218, data size field220, and read type field 226 are zero because they are not used. PIOtransaction field 222 is one, indicating a PIO transaction, and errorfield 224 is valid and, if equal to one, which would make the message aGraphics Write Error Response message, indicates that an error occurredduring the processing of the bus transaction and that the credit countis not valid. An error may occur if the remote computer module receivesmore graphics write requests messages than there is available space for,or if the remote computer module receives a graphics write requestmessage with an address that is not supported. Message head section 230includes graphics credit field 234, which indicates the number ofgraphics credits available to the requesting computer module. Eachgraphics credit is equal to one 64-bit double word of graphics data.Note that the first FLIT of a graphics request message does not need tobe counted towards the graphics credit value.

A Graphics Full 128-byte Write Request transaction may be used to write128-bytes of graphics data. The Graphics Full 128-byte Write Requestmessage has nine FLITS, and command word section 210, message headsection 230, and the entirety of the second through ninth FLITS are thevalid portions. Command word section 210 includes the fields illustratedin FIG. 4. Destination ID field 212 and source ID field 214 containidentifiers depending on which computer module is producing the requestmessage, as discussed previously. Message type field 216 is 0xA, whichindicates the message is a graphics write request, and data size field220 is 0x2, which indicates that the message contains a full 128-bytesof graphics data. Transaction number field 218 is zero becausetransaction numbers are not used, and read type field 226 is zerobecause it is also not used. PIO transaction field 222 is one, whichindicates a PIO or graphics transaction, and error field 224 is zerobecause errors should not be asserted for request messages. Message headsection 230 includes byte enable field 232 and address field 238. Byteenable field 232 indicates the number of valid bytes in the secondthrough ninth FLITS, as illustrated in Table 7. Note that if byte enablefield 232 is 0x4, data size field 220 should be 0x3, to indicate a full128-bytes of data. Address field 238 contains the address for thegraphics data write.

One possible response message is the Graphics Credit Response message.Such a message is one FLIT in size and has command word section 210 andmessage head section 230 as the valid portions. Command word section 210includes the fields illustrated in FIG. 4. Destination ID field 212 andsource ID field 214 contain identifiers depending on which computermodule is producing the request message, as discussed previously.Message type field 216 is 0xB, which indicates that the message is agraphics credit response. Transaction number field 218, data size field220, and read type field 226 are zero because they are not used. PIOtransaction field 222 is one, indicating a PIO transaction, and errorfield 224 is valid and, if equal to one, which would make the message aGraphics Write Error Response message, indicates that an error occurredduring the processing of the bus transaction and that the credit countis not valid. An error may occur if the remote computer module receivesmore graphics write requests messages than there is available space for,or if the remote computer module receives a graphics write requestmessage with an address that is not supported. Message head section 230includes graphics credit field 234, which indicates the number ofgraphics credits available to the requesting computer module. Eachgraphics credit is equal to one 64-bit double word of graphics data.Note that the first FLIT of a graphics request message does not need tobe counted towards the graphics credit value.

Another type of bus transaction that may be implemented using system 10is an Invalidate-Cache Flush transaction, which may be used to indicatethat a copy of data is no longer valid. In particular embodiments, hostcomputer module 20 uses such a transaction to inform remote computermodule 30 that a copy of data is no longer valid.

This transaction may consist only of an Invalidate-Cache Flush Requestmessage, which may consist of one FLIT. Valid portions of the messageare command word section 210 and message head section 230. Command wordsection 210 includes the fields illustrated in FIG. 4, except that thedestination ID and the source ID are not defined. Message type field 216is 0xD, which indicates that the message is an Invalidate-Cache FlushRequest. Transaction number field 218, data size field 220, and readtype field 226 are zero because they are not used. PIO transaction field222 is zero, to indicate a non-processor memory transaction. Error field224 is zero, because the error should not be asserted for requestmessages. Message head section 230 includes address field 238, whichindicates the address of the data that, if stored in the remote computermodule, should be marked as invalid.

In operation, flow control is used to manage the conveyance of dataacross signal transport device 40. Additionally, interrupts, resets,barriers, and error correction codes are used in the conveyance of data.

In particular embodiments, flow control of messages on signal transportdevice 40 is based on credits. In general, a credit is an indicationfrom a first computer module to a second computer module that the firstcomputer module has room in its buffers to receive at least a portion ofa certain type of message. Note that a portion may, for instance, besized to transfer on the appropriate one of link set 41 and link set 53in one clock period in the embodiment illustrated in FIG. 1, each linkin the appropriate set carrying part of the portion. For example, if aportion contains 128-bits in the embodiment illustrated by FIG. 1, aportion may be transferred by sending two bits on each link at a doubledata rate. In certain embodiments, flow control is different for hostcomputer module 20 to remote computer module 30 transfers than it is forremote computer module 30 to host computer module 20 transfers.

For example, for host computer module 20 to remote computer module 30transfers, credit-based flow control may be performed on PIO-transactionrequest messages sent from host computer module 20 to remote computermodule 30. Graphics write request messages and invalidate-cache flushrequest messages may be automatically accepted by remote computer module30 and, hence, do not require credit-based flow control. When remotecomputer module 30 receives a message, it examines command word section210 to determine whether the message is of a type that requirescredit-based flow control.

To implement this credit-based flow control, remote computer module 30includes credit generator 38, and host computer module 20 includescredit counter 28, as illustrated in FIG. 1. Credit generator 38controls when remote computer module 30 sends request credit signal 150,which is transferred on link 50, to credit counter 28 of host computermodule 20. When the request credit signal is asserted during a channelclock period, it indicates that remote computer module 30 has room inrequest buffer 34 for another complete PIO-transaction request messagefrom host computer module 20.

Credit generator 38 maintains a count of the number of request creditssent by remote computer module 30 to host computer module 20. In certainembodiments, this count is maintained in a memory-mapped register. Whenthe request credit signal is asserted during a channel clock period,remote computer module 30 increments the request credit count by one.When, however, remote computer module 30 receives a completePIO-transaction request message, remote computer module 30 decrementsthe request credit count by one. In particular embodiments, creditgenerator 38 has a programmable limit for the number of request creditsthat remote computer module 30 can send to host computer module 20. Therequest credit limit is stored in a memory mapped register. When thevalue of the request credit count is equal to the value of the requestcredit limit, credit generator 38 does not allow remote computer module30 to assert the request credit signal. When, however, the value of therequest credit count and less than the value of the request creditlimit, credit generator 38 allows remote computer module 30 to assertthe request credit signal.

Credit counter 28 may be a counter that tests for zero and for overflowof the credit count. In a particular embodiment, credit counter 28 is afour-bit counter. When the request credit signal is asserted during achannel clock period, credit counter 28 increments the credit count byone. When, however, a complete PIO-transaction request message transfersfrom host computer module 20 to remote computer module 30, the creditcount is decremented by one. If the credit count is zero, host computermodule 20 does not send a PIO-transaction request message to remotecomputer module 30 until the remote computer module 30 sends the requestcredit signal to host computer module 20.

It should be noted that, although they could be, response messages arenot subject to flow control in these embodiments. When remote computermodule 30 creates a request message, it automatically reserves space inresponse buffer 35 for the corresponding response message.

For transfers from remote computer module 30 to host computer module 20,credit-based flow control may be performed on all request messages. Toimplement the flow control for request messages from remote computermodule 30 to host computer module 20, host computer module 20 includescredit generator 26 and remote computer module includes credit counter36. Credit generator 26 is responsible for controlling when hostcomputer module 20 asserts credit request signal 162, which istransferred to remote computer module 30 on link 62. When the requestcredit signal is asserted during a channel clock period, it indicatesthat host computer module 20 has room in its request buffer 25 foranother 128-bit FLIT of a request message from remote computer module30.

Credit generator 26 maintains a count of the number of request creditsthat host computer module 20 has sent to remote computer module 30. Whenthe request credit signal is asserted during a channel clock period,host computer module 20 increments the request credit count by one.When, however, host computer module receives a 128-bit FLIT of a requestmessage, host computer module 20 decrements the request credit count byone.

Credit counter 36 in remote computer module 30 tests for a credit countof zero and an overflow of the credit count. When the request creditsignal is asserted during a channel clock period, credit counter 36increments the request credit count by one. When, however, a 128-bitFLIT of a request message transfers from remote computer module 30 tohost computer module 20, the credit count is decremented by one. If thecredit count is zero, remote computer module 30 does not send a requestmessage to host computer module until host computer module asserts therequest credit signal during a channel clock period. In particularembodiments, remote computer module 30 is capable of counting at leastthirty-two request credits from host computer module 20.

Credit based flow control may also be performed on response messagessent from remote computer module 30 to host computer module 20. Themajor components of this flow control are credit generator 26 and creditcounter 36. Credit generator 26 is responsible for controlling when hostcomputer module 20 sends a response credit signal to remote computermodule 30. When the response credit signal is asserted during a channelclock period, it indicates that host computer module 20 has room inresponse buffer 25 for another 128-bit FLIT of a response message fromremote computer module 30.

In operation, credit generator 26 maintains a count of the number ofresponse credits that host computer module 20 sends to remote computermodule 30. When the response credit signal is asserted during a channelclock period, host computer module 20 increments the response creditcount. When, however, host computer module 20 receives a 128-bit FLIT ofa response message, host computer module 20 decrements the responsecredit count. Credit counter 36, in turn, tests for whether the responsecredit count is zero. Also, when the response credit signal is assertedduring a channel clock period, credit counter 36 increments the responsecredit count, and when a 128-bit FLIT of a response message transfersfrom remote computer module 30 to host computer module 20, creditcounter 36 decrements the response credit count. If the credit count iszero, remote computer module 30 does not send a response message untilhost computer module 20 asserts the response credit signal. Inparticular embodiments, remote computer module 30 should be capable ofcounting at least thirty-two response credits from host computer module20.

FIG. 7 is a flowchart 700 illustrating a method for conveying data inaccordance with one embodiment of the present invention. The methodbegins at decision block 704 with determining whether a request credithas been received. The request credit could be from a host computermodule or a remote computer and could indicate that all or a portion ofa transaction request message may be sent. The request credit could beconveyed in the form of a signal, a message, or other appropriateformat.

If a request credit has been received, the method calls for determiningwhether the number of request credits has reached a limit at decisionblock 708. The limit on the number of request credits may be establisheda priori or be dynamic, possible based on the amount of availablememory. If the number of request credits has reached its limit, themethod calls for returning to decision block 704. If, however, thenumber of request credits has not reached its limit, the method callsfor incrementing a request credit counter at function block 712. Thecounter may be implemented in hardware or software and indicates thenumber of transaction request messages, or portions thereof, that may besent. The method then calls for returning to decision block 704.

If a request credit has not been received at decision block 704, themethod calls for determining whether a transaction request message is tobe sent at decision block 716. A transaction request message could, forexample, specify a read of data from non-processor memory, a write datato non-processor memory, a read of data from processor memory, a writeof data to processor memory, an atomic memory operation, and/or anyother appropriate type of operation. If a transaction request is not tobe sent, the method calls for returning to decision block 704. But if atransaction request is to be sent, the method calls for determiningwhether a request credit is available at decision block 720. Typically,determining whether a request credit is available may be ascertained byexamining the value of the request credit counter, a value greater thanzero indicating that a request message may be sent.

If a request credit is not available, the method calls for returning todecision block 704. If, however, a request credit is available, themethod calls for facilitating sending of the transaction requestmessage, or a portion thereof, at function block 724. This operation mayinvolve informing a component that the message may be sent, initiatingthe sending of the message, actually sending the message, and/or anyother appropriate operation. The method then calls for waiting for thetransaction request message, or portion thereof, to be sent at decisionblock 728. Once the transaction request message, or portion thereof, hasbeen sent, the method calls for decrementing the request credit counterat function block 732 and returning to decision block 704.

While flowchart 700 illustrates a method for conveying data inaccordance with one embodiment of the present invention, otherembodiments may contain fewer, more, and/or a different arrangement ofoperations. For example, in certain embodiments, the request creditcounter may be decremented before or while the transaction requestmessage is sent. As another example, in particular embodiments,determining whether a transaction request message is to be sent mayoccur before determining whether a request credit has been received. Asan additional example, in some embodiments, the limit on the number ofrequest credits may not be checked. As a further example, in certainembodiments, a message may be generated indicating that a transactionrequest message cannot be sent because no request credits are available.A variety of other examples exist.

FIG. 8 is a flowchart illustrating a method for conveying data inaccordance with one embodiment of the present invention. The methodbegins at decision block 804 with determining whether room is availablefor at least a portion of a transaction request message. Thedetermination may involve taking into account any transaction requestcredits previously extended, a transaction request credit indicatingthat there is room for at least part of a transaction request message.

If room is available, the method calls for determining whether thenumber of extended transaction request credits has reached its limit atdecision block 808. The amount of request credits may be set a priori ordynamically, possible based on the amount of room available. If thenumber of extended request credits is at its limit, the method calls forreturning the decision block 804. If, however, the number of extendedrequest credits is not at its limit, the method calls for initiating atransaction request credit at function block 812. The transactionrequest credit could be conveyed by a signal, a message, or any otherappropriate format and could indicate that at least a portion of atransaction request message may be sent. The method then calls forincrementing a request credit counter at function block 816. The requestcredit counter could be implemented in hardware or software. The methodthen returns to decision block 804.

If no room is available for a transaction request message, or a portionthereof, at decision block 804, the method calls for determining whethera transaction request message, or a portion thereof, has been receivedat decision block 820. If a transaction request message has not beenreceived, the method calls for returning to decision block 804. If,however, a transaction request message has been received, the methodcalls for decrementing the request credit counter at function block 824.The method then calls for returning to decision block 804.

While flowchart 800 illustrates a method for conveying data inaccordance with one embodiment of the present invention, otherembodiments may include fewer, more, and/or a different arrangement ofoperations. For example, in certain embodiments, determining whether atransaction request has been received may occur before determiningwhether there is room for a transaction request. As another example, inparticular embodiments, the limit on the number of extended transactionrequest credits may not be used. As a further example, in someembodiments, the method may include receiving a transaction responsemessage, which does not affect the transaction request credits. Avariety of other examples exist.

Note that while flowcharts 700 and 800 have discussed embodimentsimplementing transaction request credits, other embodiments couldinclude the use of transaction response credits similar to thetransaction request credits. This credit scheme could be used inconjunction with or to the exclusion of the transaction request creditscheme described above.

Another type of bus transaction that occurs on signal transport device40 is an interrupt. When an error occurs in remote computer module 30,remote computer module 30 sends an interrupt to host computer module 20to indicate that an error occurred. In particular embodiments, the errormust be enabled as a trigger for an interrupt. Because signal transportdevice 40 does not have a dedicated signal to transfer interrupts fromremote computer module 30 to host computer module 20, however, remotecomputer module 30 may send an interrupt to host computer module 20using a write interrupt transaction. In particular embodiments, remotecomputer module 30 uses a PIO 8-byte Write Interrupt transaction toassert one bit in a 256-bit interrupt register located in a destinationprocessor node or in host computer module 20. The interrupt transactionconsists of a PIO 8-byte Write Request message and a PIO 8-byte WriteResponse message with matching transaction numbers. In certainembodiments, however, before initiating an interrupt transaction, remotecomputer module 30 must perform a barrier operation, to be discussed inmore detail below, to make sure that all other outstanding PIO or memorywrite requests have finished.

The PIO 8-byte Write Request message is a two-FLIT message. Validportions of this message include command word section 210, message headsection 230, and half of the second FLIT. Command word section 210contains the fields illustrated in FIG. 4. Destination ID field 212 andsource ID field 214 contain identifiers depending on which computermodule is producing the request message, as discussed previously.Message type field 216 is 0x2, which indicates that the message is awrite request. Transaction number field 218 contains a valid transactionnumber for the write request. Data size field 220 is 0x0, whichindicates that the message contains an 8-byte double word of data. PIOtransaction field 222 is one, indicating a PIO transaction, and errorfield 224 is zero, because errors should not be asserted for requestmessages. Message head section 230 includes byte enable field 232 andaddress field 238. Byte enable field 232 indicates which bytes of thewrite data are valid. For interrupt request messages, byte enable field232 should be set to 0xFF to indicate that all of the bytes in the datafield are valid. Address field 238 contains the address of the 256-bitinterrupt processor memory location to be written to. The data field ofthe second FLIT contains an interrupt vector and an interrupt statusbit. The interrupt vector is an 8-bit value located in bits [7:0] of thedata field. The interrupt status bit is located in bit [8] of the datafield. Bits [63:9] of the data field are zero. The interrupt vectoridentifies one of the 256-bits in the destination processor memory. Theinterrupt status bit indicates that the bit identified by the interruptvector is one. For an interrupt write request, bit [8] of the data fieldis always one.

The PIO 8-byte Write Response message is a one-FLIT message. The validportions of this message include command word section 210. Command wordsection 210 includes the fields illustrated in FIG. 4. Destination IDfield 212 and source ID field 214 contain identifiers depending on whichcomputer module is producing the request message, as discussedpreviously. Message type field 216 is 0x3, which indicates that themessage is a write response. Transaction number field 218 contains thesame transaction number that was used for the corresponding interruptrequest message. Data size field 220 is 0x0, which indicates that therequest message contains 8-bytes of data, and read type field 226 iszero, because it is not used. PIO transaction field 222 is one,indicating a PIO transaction. Error field 224 is valid and, if equal toone, indicates that an error occurred during the processing of theinterrupt transaction.

In certain embodiments, remote computer module 30 automaticallygenerates the interrupt request message based on parameters stored inmemory-mapped registers. These memory-mapped registers may provide thefollowing information for interrupt generation: 1) error status forindividual errors; 2) interrupt enables for individual errors; and 3)destination parameters for the interrupt request message.

When remote computer module 30 detects that an error has occurred, itasserts the appropriate bit in the memory-mapped register, which couldbe the Coretalk Module Error Status memory-mapped register, discussed inmore detail below. For example, when remote computer module 30 detectsthat a single-bit error has occurred on the data signals on signaltransport device 40, remote computer module 30 asserts bit zero—theError Correction Code Single-Bit Error bit—of the error statusmemory-mapped register.

As mentioned previously, remote computer module 30 may generate aninterrupt message for an error only when that error is enabled as atrigger for an interrupt. In particular embodiments, a memory-mappedregister, such as the Coretalk Module Interrupt Enable memory mappedregister, enables individual errors as a trigger for an interrupt. Forexample, when bit zero—the Enable Error Correction Code Single-bit Errorbit—is asserted, remote computer module 30 generates an interrupt whenthe ECC Single-bit Error bit of the Coretalk Module Error Statusregister changes from a zero to a one. When, however, the Enable ECCSingle-bit Error bit is zero, remote computer module 30 does notgenerate an interrupt when the ECC Single-bit Error bit of the CoretalkModule Error Status register changes from a zero to a one.

The interrupt request message may require parameters for the address anddata fields of the message. This information may be stored in amemory-mapped register of remote computer module 30, such as theCoretalk Module Interrupt Destination memory mapped register. Theaddress specifies an interrupt register located in a processor node orhost computer module 20. The address field provides a means for remotecomputer module 30 to send an interrupt request message to host computermodule 20 or to a processor node in the host computer system that isdesignated to handle input/output interrupts. The register may alsoprovide an interrupt vector that is placed in the data field of theinterrupt request message. The interrupt request message specifies onebit in the 256-bit destination interrupt register that is designated asthe interrupt bit for remote computer module 30.

Signal transport device 40 also allows host computer module 20 to send areset signal to remote computer module. Such a signal would be sent overlink 65 in the illustrated embodiment. The reset could be active whilethe reset signal is asserted and could be completed when the resetsignal is de-asserted. Remote computer module 30 could have asixteen-period clock delay after the reset signal is de-asserted beforeit sends a request credit signal to host computer module.

Another type of bus operation is to barrier. A barrier is an operationthat a computer module performs to ensure that previous bus transactionscomplete before a new bus transaction begins. In particular embodiments,remote computer module 30 executes a barrier operation before beginningcertain types of operations, such as initiating an interrupt transactionthat indicates an error occurred or initiating an interrupt transactionthat indicates a memory block transfer is complete.

For a barrier for an error interrupt transaction, when an error occurs,remote computer module 30 initiates the interrupt transaction. Beforesending the interrupt transaction, however, remote computer module 30performs a barrier operation, which ensures that remote computer modulereceives a response for all of the outstanding requests it generatedbefore it detected the error interrupt condition. During the barrieroperation, remote computer module 30 halts the generation of new bustransactions. Additionally, remote computer module 30 monitors thenumber of outstanding read and write requests, which may, for example,be stored in pending read and pending write fields of a Coretalk ModuleStatus memory-mapped register. When the pending reads and pending writeshave been completed, the barrier operation is complete, and remotecomputer module 30 resumes the generation of new bus transactions.Accordingly, the first bus transaction that remote computer module 30generates is the interrupt transaction for the error.

In particular embodiments, remote computer module 30 may contain logicthat can be programmed to transfer large amounts of data, or blocks, toand from the non-processor memory of host computer module 20. Forexample, memory-mapped registers in the block-transfer logic may containa starting address, a transfer length, an address increment value, and aread-or-write designation for the transfer. When software stores valuesinto the memory-mapped registers, the block-transfer logic performs theassociated memory transactions.

In particular embodiments, there may be an enable bit and a status bitfor implementing such a transaction. For example, the Coretalk InterruptEnable memory-mapped register may have a bit to enable the transaction,and the Coretalk Error Status memory-mapped register may have a bit toindicate when to initiate the interrupt transaction. Before sending theinterrupt transaction, remote computer module 30 may perform a barrieroperation, to ensure that remote computer module 30 receives a responsefor all the outstanding memory read or write requests that it generatedbefore it sends the interrupt transaction for the block-transferinterrupt. During the barrier operation, remote computer module 30 mayhalt the generation of new read or write bus transactions and monitorthe number of outstanding read or write requests, which may also bestored in appropriate fields of a memory-mapped register, such as theCoretalk Status memory-mapped register. When the pending read or writeshave been completed, the barrier operation is complete, and the remotecomputer module resumes the generation of new read or write bustransactions, the first being the interrupt transaction for theblock-transfer interrupt. Note that when a barrier operation isperformed for read transactions, write transactions may proceed onsignal transport device 40, and when a barrier operation is performedfor write transactions, read transactions may proceed on the signaltransport device.

In particular embodiments, the Error Correction Code (ECC) is an 8-bitcode that covers 64-bits of data. The code may be capable of detectingand correcting single-bit errors, double-bit errors, and/or multiple-biterrors. In certain embodiments, the ECC is capable of detecting andcorrecting single-bit errors, detecting double-bit errors, and detectingsome multiple-bit errors.

In operation, a transmitter of data on signal transport device 40generates the ECC check bits. Table 14 lists the ECC check bitassignments for 64-bits of data for certain embodiments. The value ofeach check bit is derived from the parity of the data bits denoted inTable 14. For example, if Data [63:0] bits are equal to0x0000000000000007, the ECC [7:0] bits should be equal to 0xC7.

TABLE 14 ECC ECC ECC ECC ECC ECC ECC ECC Bits [7] [6] [5] [4] [3] [2][1] [0] Data [0] X X X Data [1] X X X Data [2] X X X Data [3] X X X Data[4] X X X Data [5] X X X Data [6] X X X Data [7] X X X Data [8] X X XData [9] X X X Data [10] X X X Data [11] X X X Data [12] X X X Data [13]X X X Data [14] X X X Data [15] X X X Data [16] X X X Data [17] X X XData [18] X X X Data [19] X X X Data [20] X X X Data [21] X X X Data[22] X X X Data [23] X X X Data [24] X X X X X Data [25] X X X X X Data[26] X X X Data [27] X X X Data [28] X X X Data [29] X X X Data [30] X XX X X Data [31] X X X X X Data [32] X X X Data [33] X X X Data [34] X XX Data [35] X X X Data [36] X X X Data [37] X X X Data [38] X X X Data[39] X X X Data [40] X X X Data [41] X X X Data [42] X X X Data [43] X XX Data [44] X X X Data [45] X X X Data [46] X X X Data [47] X X X Data[48] X X X Data [49] X X X Data [50] X X X Data [51] X X X Data [52] X XX Data [53] X X X Data [54] X X X Data [55] X X X Data [56] X X X X XData [57] X X X X X Data [58] X X X Data [59] X X X Data [60] X X X Data[61] X X X Data [62] X X X X X Data [63] X X X X X

The receiving computer module on signal transport device 40 generatesECC Syndrome bits. The value of each syndrome bit is derived from theparity of the data bits and check bits. Table 15 illustrates theassignment of Data [63:0] bits and ECC [7:0] bits to ECC syndrome bits(S[7:0]) for certain embodiments.

TABLE 15 Bits S [7] S [6] S [5] S [4] S [3] S [2] S [1] S [0] Data [0] XX X Data [1] X X X Data [2] X X X Data [3] X X X Data [4] X X X Data [5]X X X Data [6] X X X Data [7] X X X Data [8] X X X Data [9] X X X Data[10] X X X Data [11] X X X Data [12] X X X Data [13] X X X Data [14] X XX Data [15] X X X Data [16] X X X Data [17] X X X Data [18] X X X Data[19] X X X Data [20] X X X Data [21] X X X Data [22] X X X Data [23] X XX Data [24] X X X X X Data [25] X X X X X ECC [2] X ECC [5] X Data [26]X X X Data [27] X X X Data [28] X X X Data [29] X X X Data [30] X X X XX Data [31] X X X X X ECC [3] X ECC [4] X Data [32] X X X Data [33] X XX Data [34] X X X Data [35] X X X Data [36] X X X Data [37] X X X Data[38] X X X Data [39] X X X Data [40] X X X Data [41] X X X Data [42] X XX Data [43] X X X Data [44] X X X Data [45] X X X Data [46] X X X Data[47] X X X Data [48] X X X Data [49] X X X Data [50] X X X Data [51] X XX Data [52] X X X Data [53] X X X Data [54] X X X Data [55] X X X Data[56] X X X X X Data [57] X X X X X ECC [6] X ECC [1] X Data [58] X X XData [59] X X X Data [60] X X X Data [61] X X X Data [62] X X X X X Data[63] X X X X X ECC [7] X ECC [0] X

When the value of the syndrome bits is 0x00, it indicates that thevalues of the data bits and ECC bits are the same as they were when theywere originally transmitted. In this case, no error has occurred. Note,however, that it is possible that many, for example more than five, ofthe data and/or ECC bits have changed value and the derived value of thesyndrome bits turns out to be 0x00, which would indicate that no erroroccurred; this is actually a case of an undetectable error.

When the parity of the syndrome bits is odd and a three-bit or afour-bit error is not detected, it indicates that a single-bit erroroccurred. When the receiving computer module detects a single-bit error,it uses the syndrome bit to determine which data or ECC bit is notcorrect and corrects the value of that bit. The receiving computermodule may also set a single-bit error bit in an error status register.Table 16 lists the values of the syndrome bits and indicates which dataor ECC bit corresponds to each syndrome code for certain embodiments.For example, when the syndrome bits are set to 0xC2, it indicates thatData [1] bit one is not correct.

TABLE 16 Syndrome S S S Code Bits [7] S [6] [5] S [4] [3] S [2] S [1] S[0] S [7:0] Data [0] 1 1 0 0 0 0 0 1 0xC1 Data [1] 1 1 0 0 0 0 1 0 0xC2Data [2] 1 1 0 0 0 1 0 0 0xC4 Data [3] 1 1 0 0 1 0 0 0 0xC8 Data [4] 1 01 0 0 0 0 1 0xA1 Data [5] 1 0 1 0 0 0 1 0 0xA2 Data [6] 1 0 1 0 0 1 0 00xA4 Data [7] 1 0 1 0 1 0 0 0 0xA8 Data [8] 1 0 0 1 0 0 0 1 0x91 Data[9] 1 0 0 1 0 1 0 0 0x92 Data [10] 1 0 0 1 0 1 0 0 0x94 Data [11] 1 0 01 1 0 0 0 0x98 Data [12] 0 1 1 0 0 0 0 1 0x61 Data [13] 0 1 1 0 0 0 1 00x62 Data [14] 0 1 1 0 0 1 0 0 0x64 Data [15] 0 1 1 0 1 0 0 0 0x68 Data[16] 0 1 0 1 0 0 0 1 0x51 Data [17] 0 1 0 1 0 0 1 0 0x52 Data [18] 0 1 01 0 1 0 0 0x54 Data [19] 0 1 0 1 1 0 0 0 0x58 Data [20] 0 0 1 1 0 0 0 10x31 Data [21] 0 0 1 1 0 0 1 0 0x32 Data [22] 0 0 1 1 0 1 0 0 0x34 Data[23] 0 0 1 1 1 0 0 0 0x38 Data [24] 1 1 1 1 1 0 0 0 0xF8 Data [25] 0 1 00 1 1 1 1 0x4F Data [26] 0 1 1 1 0 0 0 0 0x70 Data [27] 1 1 0 1 0 0 0 00xD0 Data [28] 0 0 0 0 1 1 1 0 0x0E Data [29] 0 0 0 0 1 0 1 1 0x0B Data[30] 1 1 1 1 0 0 0 1 0xF1 Data [31] 0 0 1 0 1 1 1 1 0x2F Data [32] 0 0 01 1 1 0 0 0x1C Data [33] 0 0 1 0 1 1 0 0 0x2C Data [34] 0 1 0 0 1 1 0 00x4C Data [35] 1 0 0 0 1 1 0 0 0x8C Data [36] 0 0 0 1 1 0 1 0 0x1A Data[37] 0 0 1 0 1 0 1 0 0x2A Data [38] 0 1 0 0 1 0 1 0 0x4A Data [39] 1 0 00 1 0 1 0 0x8A Data [40] 0 0 0 1 1 0 0 1 0x19 Data [41] 0 0 1 0 1 0 0 10x29 Data [42] 0 0 1 0 1 0 0 1 0x49 Data [43] 1 0 0 0 1 0 0 1 0x89 Data[44] 0 0 0 1 0 1 1 0 0x16 Data [45] 0 0 1 0 0 1 1 0 0x26 Data [46] 0 1 00 0 1 1 0 0x46 Data [47] 1 0 0 0 0 1 1 0 0x86 Data [48] 0 0 0 1 0 1 0 10x15 Data [49] 0 0 1 0 0 1 0 1 0x25 Data [50] 0 1 0 0 0 1 0 1 0x45 Data[51] 1 0 0 0 0 1 0 1 0x85 Data [52] 0 0 0 1 0 0 1 1 0x13 Data [53] 0 0 10 0 0 1 1 0x23 Data [54] 0 1 0 0 0 0 1 1 0x43 Data [55] 1 0 0 0 0 0 1 10x83 Data [56] 1 0 0 0 1 1 1 1 0x8F Data [57] 1 1 1 1 0 1 0 0 0xF4 Data[58] 0 0 0 0 0 1 1 1 0x07 Data [59] 0 0 0 0 1 1 0 1 0x0D Data [60] 1 1 10 0 0 0 0 0xE0 Data [61] 1 0 1 1 0 0 0 0 0xB0 Data [62] 0 0 0 1 1 1 1 10x1F Data [63] 1 1 1 1 0 0 1 0 0xF2 ECC [0] 0 0 0 0 0 0 0 1 0x00 ECC [1]0 0 0 0 0 0 1 0 0x02 ECC [2] 0 0 0 0 0 1 0 0 0x04 ECC [3] 0 0 0 0 1 0 00 0x08 ECC [4] 0 0 0 1 0 0 0 0 0x10 ECC [5] 0 0 1 0 0 0 0 0 0x20 ECC [6]0 1 0 0 0 0 0 0 0x40 ECC [7] 1 0 0 0 0 0 0 0 0x80

The receiving computer module detects a multiple-bit error when athree-bit or a four-bit error occurs or when a double-bit error occurs.The receiving computer module detects a double-bit error when the parityof the syndrome bit S [7:0] is even and the syndrome bits are not equalto zero. When the receiver detects a multiple-bit error, it may set themultiple-bit error bit in an error status register. The receivingcomputer module typically cannot correct data or ECC bits when amultiple bit error occurs.

The receiving computer module may detect a three-bit or a four-bit errorwhen either of the following conditions occur: 1) syndrome bits S [3:0]are not equal to zero and syndrome bits S [7:4] are equal to 0x7, 0xB,0xD, or 0xE, indicating that three bits are set to one; or (2) syndromebits S [7:4] are not equal to zero and syndrome bits S [3:0] are equalto 0x7, 0xB, 0xD, or 0xE, indicating that three bits are set to one.When the receiving computer module detects a three-bit or a four-biterror, it may set the multiple-bit error bit in the error statusregister.

As mentioned previously, in particular embodiments, remote computermodule (RCM) 30 has memory-mapped registers. These registers may beaccessed by host computer module (HCM) 20 by, for example, using PIORead transactions or PIO Write transactions.

In certain embodiments, the memory-mapped registers are accessible byhost computer module 20 using PIO 8-byte Read or PIO 8-byte Writetransactions. These registers are accessed using the 56-bit Coretalkmemory address space. The register addresses are on 8-byte boundaries,so bits [2:0] of the register addresses are zero. In addition, thebyte-enable field of PIO 8-byte Read Request messages and PIO 8-byteWrite Request messages should be 0xFF to access the registers. Inparticular embodiments, at least the lower 256-bytes of the Coretalkaddress space in a remote computer module is reserved for configurationand status registers.

Table 17 lists the registers that a remote computer module in compliancewith the Coretalk standard may provide to conform with correct operationof the bus. Details on the fields used in these registers is providedbelow.

TABLE 17 Register Name Register Address CM_ID 0x00_0000_0000_0000CM_STATUS 0x00_0000_0000_0008 CM_ERROR_STATUS 0x00_0000_0000_0060CM_CLEAR_ERROR_STATUS 0x00_0000_0000_0068 CM_ERROR_DETAIL_10x00_0000_0000_0010 CM_ERROR_DETAIL_2 0x00_0000_0000_0018CM_INTERRUPT_ENABLE 0x00_0000_0000_0070 CM_INTERRUPT_DEST0x00_0000_0000_0038 CM_CONTROL 0x00_0000_0000_0020 CM_REQUEST_TIMEOUT0x00_0000_0000_0028 CM_TARGET_FLUSH 0x00_0000_0000_0050CM_CACHED_TIMEOUT 0x00_0000_0000_0080

The Coretalk Module Identification (CM_ID) register is a read-onlyregister that contains information that identifies the manufacturer,part number, and revision number of the remote computer module. TheCM_ID register may conform to the IEEE 1149.1 JTAG Device IdentificationRegister standard. Table 18 illustrates the fields of the register.

TABLE 18 Bits Access Reset Value Field Name 0 RO 1 READ_AS_ONE 11:1  ROx MANUFACTURER 27:12 RO x PART_NUMBER 31:28 RO x REVISION_NUMBER 63:32RO 0 RESERVED

The fields are defined as follows:

READ_AS_ONE—This field is not used and when read, always returns a one;

MANUFACTURER—This field contains an eleven-bit value that identifies themanufacturer of the RCM;

PART_NUMBER—This field contains a sixteen-bit value that identifies thepart number of the RCM;

REVISION_NUMBER—This field contains a four-bit value that identifies therevision of the RCM; and

RESERVED—These bits are reserved for future use.

The Coretalk Module Status (CM STATUS) register is a read-only registerthat contains information on the current status of credit counters andthe number of pending read and write requests issued by the remotecomputer module. Table 19 illustrates the fields of the register.

TABLE 19 Bits Access Reset Value Field Name 5:0 RO 0 PENDING_READS 7:6RO x RESERVED 12:8  RO 0 PENDING_WRITES 15:13 RO x RESERVED 23:16 RO xHCM_RSP_CREDITS 31:24 RO x HCM_REQ_CREDITS 35:32 RO x CM_REQ_CREDITS63:36 RO x CM_DEFINED

The fields are defines as follows:

PENDING_READS—This field indicates the number of read request messagestransmitted by the RCM for which the HCM has not yet transmitted acorresponding read response message (Read request messages include:Memory 8-byte Read Request Messages Ge—; Cached, Not Timed; or CachedTimed); Memory 128-byte Read Request Messages—Get; Cached, Not Timed; orCached Timed); PIO 8-byte Read Request Messages; PIO Full 128-byte ReadRequest Messages; and Fetch AMO Request Messages.);

RESERVED—These bits are reserved for future use;

PENDING_WRITES—This field indicates the number of write request messagestransmitted by the RCM for which the HCM has not yet transmitted acorresponding write response message (Write request messages include:Memory Full 128-byte Write Request Messages; Memory Partial 128-byteWrite Request Messages; PIO 8-byte Write Request Messages; PIO Partial128-byte Write Request Messages; and Store AMO Request Messages.);

RESERVED—These bits are reserved for future use;

HCM_RSP_CREDITS—This field indicates the number of response credits thatthe RCM has received from the HCM (The HCM uses the Response Creditsignal to indicate to the RCM that the HCM has room in its responsebuffer for another individual 128-bit FLIT of a response message; thus,this field indicates the number of 128-bit response message FLITS thatthe RCM may send to the HCM.);

HCM_REQ_CREDITS—This field indicates the number of request credits that10 the RCM has received from the HCM (The HCM uses the Request Creditsignal to indicate to the RCM that the HCM has room in its requestbuffer for another individual 128-bit FLIT of a request message; thus,this field indicates the number of 128-bit request message flits thatthe RCM may send to the HCM.);

CM_REQ_CREDITS—This field indicates the number of request credits thatthe RCM has sent to the HCM (The RCM uses the Request Credit signal toindicate to the HCM that the RCM has room in its request buffer foranother complete request message; thus, this field indicates the numberof complete request messages that the HCM may send to the RCM.); and

CM_DEFINED—These bits are defined by the designer of the RCM.

The Coretalk Module Error Status (CM_ERROR_STATUS) register is areadable and writable register that indicates when specific bus errorshave occurred. The CM_ERROR_STATUS register should not be modified by areset. Writing to the CM_ERROR_STATUS register overwrites all values inthe register. Writing to the CM_CLEAR_ERROR_STATUS register clearsindividual hits in the CM_ERROR_STATUS register without affecting theother bits in the register. Table 20 illustrates the fields of theregister.

TABLE 20 Bits Access Reset Value Field Name 0 RW x ECC_SBE 1 RW xECC_MBE 2 RW x UNSUPPORTED_REQ 3 RW x UNEXPECTED_RSP 4 RW x BAD_LENGTH 5RW x BAD_DATAVALID 6 RW x BUFFER_OVERFLOW 7 RW x REQUEST_TIMEOUT 16:8 RW x RESERVED 63:17 RW x CM_DEFINED

The fields are defined as follows:

ECC_SBE—When equal to one, this bit indicates that the RCM detected asingle-bit error on the bus using the ECC that it received on the ECC[7:0] signals;

ECC_MBE—When equal to one, this bit indicates that the RCM detected amultiple-bit error on the bus using the ECC that it received on the ECC[7:0] signals;

UNSUPPORTED_REQ—When equal to one, this bit indicates that the RCMreceived a request message that the RCM does not support (For example,if the RCM received a Fetch AMO Request message, the RCM would set thisbit to one; more information on the request message that caused theerror is provided in the CM_ERROR_DETAIL_(—)1 and CM_ERROR_DETAIL_(—)2registers.);

UNEXPECTED_RSP—When equal to one, this bit indicates that the RCMreceived a response message that the RCM was not expecting (Moreinformation on the response message that caused the error is provided inthe CM_ERROR_DETAIL_(—)1 and CM_ERROR_DETAIL_(—)1 registers.);

BAD_LENGTH—When equal to one, this hit indicates that the RCM received amessage in which the number of FLITS did not match the correct number offlits for that message type (More information on the message that causedthe error is provided in the CM_ERROR_DETAIL_(—)1 andCM_ERROR_DETAIL_(—)2 registers.);

BAD_DATAVALID—When equal to one, this bit indicates that the RCMdetected that the Request Valid and Response Valid signals were assertedat the same time on the bus;

BUFFER_OVERFLOW—When equal to one, this bit indicates that the RCMreceived more request messages than it has room for in its requestbuffer (The RCM asserts the request credit signal once for each requestmessage that it can receive from the HCM. If the HCM sends more requestmessages than the number of request credits the RCM generated, the RCMsets this bit to one; more information on the message that caused theerror is provided in the CM_ERROR_DETAIL_(—)1 and CM_ERROR_DETAIL_(—)2registers);

REQUEST_TIMEOUT—When equal to one, this bit indicates that the RCM senta request message for which it did not receive a corresponding responsemessage before a time-out counter expired (The value of the time-outcounter is specified in the CM_REQUEST_TIMEOUT register.);

RESERVED—This bits are reserved for future use; and

CM_DEFINED—These bits are defined by the designer of the RCM.

The Coretalk Module Clear Error Status (CM_CLEAR_ERROR_STATUS) registeris a readable and writable register that clears individual bits in theCM_ERROR_STATUS register. When the CM_CLEAR_ERROR_STATUS register isread, the value of each bit is zero. Table 21 illustrates the fields ofthe register.

TABLE 21 Bits Access Reset Value Field Name 0 RW x CLEAR_ECC_SBE 1 RW xCLEAR_ECC_MBE 2 RW x CLEAR_UNSUPPORTED_REQ 3 RW x CLEAR_UNEXPECTED_RSP 4RW x CLEAR_BAD_LENGTH 5 RW x CLEAR_BAD_DATAVALID 6 RW xCLEAR_BUFFER_OVERFLOW 7 RW x CLEAR_REQUEST_TIMEOUT 16:8  RW x RESERVED63:17 RW x CLEAR_CM_DEFINED

The fields are defined as follows:

CLEAR_ECC_SBE—When this bit is one, the RCM clears the ECC_SBE bit inthe CM_ERROR_STATUS register, but when the CLEAR_ECC_SBE bit is zero,the value of the ECC_SBE bit is not changed;

CLEAR_ECC_MBE—When this bit is one, the RCM clears the ECC_MBE bit inthe CM_ERROR_STATUS register, but when the CLEAR_ECC_MBE bit is zero,the value of the ECC_MBE bit is not changed;

CLEAR_UNSUPPORTED_REQ—When this bit is one, the RCM clears theUNSUPPORTED_REQ bit in the CM_ERROR_STATUS register and the VALID bit inthe CM_ERROR_DETAIL_(—)1 register (This action re-enables the capture oferror details in the ERROR_DETAIL_(—)1 and CM_ERROR_DETAIL_(—)2registers, but when the this bit is zero, the value of theUNSUPPORTED_REQ bit is not changed.);

CLEAR_UNEXPECTED_RSP—When this bit is one, the RCM clears theUNEXPECTED_RSP bit in the CM_ERROR_STATUS register and the VALID bit inthe CM_ERROR_DETAIL_(—)1 register (This action re-enables the capture oferror details in the CM_ERROR_DETAIL_(—)1 and CM_ERROR_DETAIL_(—)2registers, but when this bit is zero, the value of the UNEXPECTED_RSPbit is not changed.);

CLEAR_BAD_LENGTH—When this bit is one, the RCM clears the BAD_LENGTH bitin the CM_ERROR_STATUS register and the VALID bit in theCM_ERROR_DETAIL_(—)1 register (This action re-enables the capture oferror details in the CM_ERROR_DETAIL_(—)1 and CM_ERROR_DETAIL_(—)2registers, but when this bit is zero, the value of the BAD_LENGTH bit isnot changed.);

CLEAR_BAD_DATAVALID—When this bit is one, the RCM clears theBAD_DATAVALID bit in the CM_ERROR_STATUS register (When this bit iszero, however, the value of the BAD_DATAVALID bit is not changed.);

CLEAR_BUFFER_OVERFLOW—When this bit is one, the RCM clears theBUFFER_OVERFLOW bit in the CM_ERROR_STATUS register and the VALID bit inthe CM_ERROR_DETAIL_(—)1 register (This action re-enables the capture oferror details in the CM_ERROR_DETAIL_(—)1 and CM_ERROR_DETAIL_(—)2registers, but when this bit is zero, the value of the BUFFER_OVERFLOWbit is not changed.);

CLEAR_REQUEST_TIMEOUT—When this bit is one, the RCM clears theREQUEST_TIMEOUT bit in the CM_ERROR_STATUS register (When this bit iszero, however, the value of the REQUEST_TIMEOUT bit is not changed.);

RESERVED—This bits are reserved for future use; and

CLEAR_CM_DEFINED—When a bit in this field is one, the RCM clears thecorresponding bit in the CM_DEFINED field of the CM_ERROR_STATUSregister (When a bit in this is zero, however, the corresponding bit inthe CM_DEFINED field of the CM_ERROR_STATUS register is not changed.).

The Coretalk Module Error Detail 1 (CM_ERROR_DETAIL_(—)1) register is aread-only register that stores the message head fields from the firstmessage that caused an UNSUPPORTED_REQ, UNEXPECTED_RSP, BAD_LENGTH, orBUFFER_OVERFLOW error reported in the CM_ERROR_STATUS register. TheCM_ERROR_DETAIL_(—)1 register should not be modified by a reset. Table22 illustrates the fields for this register.

TABLE 22 Bits Access Reset Value Field Name 3:0 RO x MESSAGE_TYPE 5:4 ROx SOURCE_ID 7:6 RO x DATA_SIZE 15:8  RO x TNUM 23:16 RO x BYTE_ENABLE31:24 RO x GFX_CRED 33:32 RO x READ_TYPE 34 RO x PIO_OR_MEMORY 35 RO xHEAD_CW_ERROR 47:36 RO x RESERVED 48 RO x HEAD_ERROR_BIT 49 RO xDATA_ERROR_BIT 62:50 RO x RESERVED 63 RO x VALID

The fields are defined as follows:

MESSAGE_TYPE—When the VALID hit is one, this field contains the value ofthe Message Type field in the command word of the first message to causean error bit in the CM_ERROR_STATUS register to set;

SOURCE_ID—When the VALID bit is one, this field contains the value ofthe Source ID field in the command word of the first message to cause anerror bit in the CM_ERROR_STATUS register to set;

DATA_SIZE—When the VALID bit is one, this field contains the value ofthe Data Size field in the command word of the first message to cause anerror bit in the CM_ERROR_STATUS register to set;

TNUM—When the VALID bit is one, this field contains the value of theTransaction Number field in the command word of the first message tocause an error bit in the CM_ERROR_STATUS register to set;

BYTE_ENABLE—When the VALID bit is one, this field contains the value ofthe Byte Enable field in the head of the first message to cause an errorbit in the CM_ERROR_STATUS register to set (The Byte Enable field is notvalid for all message types.);

GFX_CRED—When the VALID bit is one, this field contains the value of theGraphics Credit field in the head of the first message to cause an errorbit in the CM_ERROR_STATUS register to set (The Graphics Credit field isnot valid for all message types.);

READ_TYPE—When the VALID hit is one, this field contains the value ofthe Read Type field in the command word of the first message to cause anerror bit in the CM_ERROR_STATUS register to set (The Read Type field isnot valid for all message types.);

PIO_OR_MEMORY—When the VALID bit is one, this bit contains the value ofthe PIO Transaction bit in the command word of the first message tocause an error bit in the CM_ERROR_STATUS register to set;

HEAD_CW_ERROR—When the VALID bit is one, this bit contains the value ofthe Error bit in the command word of the first message to cause an errorbit in the CM_ERROR_STATUS register to set;

RESERVED—These bits are reserved for future use;

HEAD_ERROR_BIT—When the VALID bit is one, this bit contains the value ofthe Error signal for the message head when the RCM received the message;

DATA_ERROR_BIT—When the VALID bit is one, this bit contains the value ofthe Error signal for the message data payload when the RCM received themessage;

RESERVED—These bits are reserved for future use; and

VALID—When this bit is one, it indicates that the CM_ERROR_DETAIL_(—)1and CM_ERROR_DETAIL_(—)2 registers contain the message head informationfor the first message to cause an error bit in the CM_ERROR_STATUSregister to set, and when this bit is zero, it indicates that theCM_ERROR_DETAIL_(—)1 and CM_ERROR_DETAIL_(—)2 registers are enabled, butdo not contain valid message head information.

The Coretalk Module Error Detail 2 (CM_ERROR_DETAIL_(—)2) register is aread-only register that stores the address field from the first messagethat causes an UNSUPPORTED_REQ, UNEXPECTED_RSP, BAD_LENGTH, orBUFFER_OVERFLOW error reported in the CM_ERROR_STATUS register. TheCM_ERROR_DETAIL_(—)2 register should not be modified by a reset. Table23 illustrates the fields for this register.

TABLE 23 Bits Access Reset Value Field Name 55:0  RO x ADDRESS 63:56 ROx RESERVED

The fields for this register are defined as follows:

ADDRESS—When the VALID bit of the CM_ERROR_DETAIL_(—)1 register is one,this field contains the value of the Address field of the first messageto cause an error bit in the CM_ERROR_STATUS register to set (TheAddress field is not valid for all message types.); and

RESERVED—These bits are reserved for future used.

The Coretalk Module Interrupt Enable (CM_INTERRUPT_ENABLE) register is areadable and writable register that enables the generation of aninterrupt message when selected errors are reported in theCM_ERROR_STATUS register. The interrupt message is a PIO 8-byte WriteRequest message that the remote computer module sends to a processor inthe computer system that is designated to handle interrupts. The addressfor the interrupt message is defined in the CM_INTERRUPT_DEST register.Table 24 illustrates the fields for this register.

TABLE 24 Bits Access Reset Value Field Name 0 RW 0 ENABLE_ECC_SBE 1 RW 0ENABLE_ECC_MBE 2 RW 0 ENABLE_UNSUPPORTED_REQ 3 RW 0ENABLE_UNEXPECTED_RSP 4 RW 0 ENABLE_BAD_LENGTH 5 RW 0ENABLE_BAD_DATAVALID 6 RW 0 ENABLE_BUFFER_OVERFLOW 7 RW 0ENABLE_REQUEST_TIMEOUT 16:8  RW 0 RESERVED 63:17 RW 0 ENABLE_CM_DEFINED

The fields for this register are defined as follows:

ENABLE_ECC_SBE—When this bit is one, the RCM generates an interruptmessage when the ECC_SBE bit in the CM_ERROR_STATUS register changesfrom zero to one;

ENABLE_ECC_MBE—When this bit is one, the RCM generates an interruptmessage when the ECC_MBE bit in the CM_ERROR_STATUS register changesfrom zero to one;

ENABLE_UNSUPPORTED_REQ—When this bit is one, the RCM generates aninterrupt message when the UNSUPPORTED_REQ bit in the CM_ERROR_STATUSregister changes from zero to one;

ENABLE_UNEXPECTED_RSP—When this bit is one, the RCM generates aninterrupt message when the UNEXPECTED_RSP bit in the CM_ERROR_STATUSregister changes from zero to one;

ENABLE_BAD_LENGTH—When this bit is one, the RCM generates and interruptmessage when the BAD_LENGTH bit in the CM_ERROR_STATUS register changesfrom zero to one;

ENABLE_BAD_DATAVALID—When this bit is one, the RCM generates aninterrupt message when the BAD_DATAVALID bit in the CM_ERROR_STATUSregister changes from zero to one;

ENABLE_BUFFER_OVERFLOW—When this bit is one, the RCM generates aninterrupt message when the BUFFER_OVERFLOW bit in the CM_ERROR_STATUSregister changes from zero to one;

ENABLE_REQUEST_TIMEOUT—When this bit is one, the RCM generates aninterrupt message when the REQUEST_TIMEOUT bit in the CM_ERROR_STATUSregister changes from zero to one;

RESERVED—This bits are reserved for future use; and

ENABLE_CM_DEFINED—When a bit in this field is one, the RCM generates aninterrupt message when the corresponding bit in the CM_DEFINED field ofthe CM_ERROR_STATUS register changes from zero to one.

The Coretalk Module Interrupt Destination (CM_INTERRUPT_DEST) registeris a readable and writable register that contains an address used forinterrupt messages. An interrupt message is a PIO 8-byte Write Requestmessage that the remote computer module sends to a processor interfacein the computer system that is designated to handle interrupts. Table 25illustrates the fields for this register.

TABLE 25 Bits Access Reset Value Field Name 55:0  RW x ADDRESS 63:56 RWx INT_VECTOR

The fields for this register are defined as follows:

ADDRESS—This field contains the 56-bit address used in the Address fieldof interrupt messages (Interrupt messages are PIO 8-byte Write Requestmessages that the RCM sends to a processor interface in the computersystem.); and

INT_VECTOR—This field contains an interrupt vector for the processorinterface that is designated to handle interrupts.

The Coretalk Module Control (CM_CONTROL) register is a readable andwritable register that sets various identification and configurationparameters for the remote computer module. Table 26 illustrates thefields for this register.

TABLE 26 Bits Access Reset Value Field Name 1:0 RW 0x3 CM_ID 3:2 RW xRESERVED 10:4  RW Refer to MAX_TRANS Description 11 RW x RESERVED 12 RW0x1 ADDRESS_MODE 15:13 RW x RESERVED 16 RW 0x0 FORCE_ECC_SBE 17 RW 0x0FORCE_ECC_MBE 19:18 RW x RESERVED 27:20 RW Refer to CREDIT_LIMITDescription 31:21 RW x RESERVED 63:32 RW x CM_DEFINED

The fields for this register are defined as follows:

CM_ID—This field contains a value used for the Source ID field in thecommand word of messages sent by the RCM to the HCM;

RESERVED—These bits are reserved for future use;

MAX_TRANS—This field contains a value that indicates the maximum numberof outstanding transactions that the RCM will allow (An outstandingtransaction occurs when the RCM has not received a correspondingresponse message to a request message; when the number of outstandingtransactions equals the value in this field, the RCM does not create newrequest messages until the number of outstanding transactions decreases;the reset value of this field should be the maximum number ofoutstanding transactions the RCM will allow.);

RESERVED—This bit is reserved for future use;

ADDRESS_MODE—This bit indicates the addressing mode that the computersystem uses to address memory (When zero, the addressing mode is LittleEndian, and when one, the addressing mode is Big Endian.);

RESERVED—These bits are reserved for future use;

FORCE_ECC_SBE—When this bit is one, the RCM generates ECC for the nextbus transaction that will cause the HCM to detect a single-bit error(After generating the single-bit error ECC one time, the RCM returns tonormal bus operation.);

FORCE_ECC_MBE—When this bit is one, the RCM generates ECC for the nextbus transaction that will cause the HCM to detect a multiple-bit error(After generating the multiple-bit error ECC one time, the RCM returnsto normal bus operation.);

RESERVED—These bits are reserved for future use;

CREDIT_LIMIT—This field contains a value that indicates the maximumnumber of request credits that the RCM will send to the HCM (The resetvalue of this field should be the maximum number of request credits thatthe HCM can receive.);

RESERVED—These bits are reserved for future use; and

CM_DEFINED—These bits are defined by the designer of the RCM.

The Coretalk Module Request Timeout (CM_REQUEST_TIMEOUT) register is areadable and writable register that contains a maximum value for requesttime-out counters in the RCM. The RCM should have a prescaler thatgenerates a pulse on the order of 1.00 to 1.28 microseconds thatdecrements the request time-out counters. Table 27 illustrates thefields for this register.

TABLE 27 Bits Access Reset Value Field Name 23:0  RW 0xFFFFFF TIME_OUT63:24 RW x RESERVED

The fields are defined as follows:

TIME_OUT—When this field is zero, the request time-out counter in theRCM is disabled, and when this field is greater than zero, the requesttime-out counter in the RCM is enabled. (When enabled, the time-outcounter is a free-running counter that repeatedly counts from zero tothe TIME_OUT value; each time the counter restarts at zero, alloutstanding requests are marked, and if an outstanding request isalready marked when the counter restarts at zero, that request isconsidered to have timed out; the actual time-out period for anoutstanding request depends on when the request is created; if therequest is created when the time-out counter is at the TIME_OUT value,the request will time out in the minimum amount of time, which is theTIME_OUT value; if the request is created when the time-out counter iszero, the request will timeout in the maximum amount of time, which istwice the TIME_OUT value; when a request transaction times out, the RCMsets the REQUEST_TIMEOUT bit in the CM_ERROR_STATUS register to one; ifenabled by the CM_INTERRUPT_ENABLE register, the RCM also generates aninterrupt message and sends the message to a processor interface in thecomputer system that is designed. to handle interrupts; if the RCMreceives the corresponding response message after indicating aREQUEST_TIMEOUT error, the RCM reports an UNEXPECTED_RSP error in theCM_ERROR_STATUS register.); and

Reserved—These bits are reserved for future use.

The Coretalk Module Target Flush (CM_TARGET_FLUSH) register is aread-only register that indicates when the RCM has completed thetransactions for all of the request messages that it received. Thisregister is required in RCMs that support pipelining of transactions.Table 28 illustrates the fields for this register.

TABLE 28 Bits Access Reset Value Field Name 63:0 RO 0 TARGET_FLUSH_VALUE

The field is defined as follows:

TARGET_FLUSH_VALUE—When this field is zero, it indicates that the RCMhas completed the transactions for all of the request messages that itreceived, and when this field is not zero, it indicates that the RCM isstill processing transactions for one or more request messages that itreceived.

The Coretalk Module Cached Time-out (CM_CACHED_TIMEOUT) register is areadable and writable register that controls the frequency at which thecached-timed read-request timeout counter increments. The RCM and theHCM have memory-mapped registers that control the duration of thecached-timed read-request timeout. When the RCM issues a cached-timedread-request to the HCM, it notes the current value of its free-runningcounter. The RCM detects a timeout condition when data from acached-time read-request has been in the cache memory of the RCM longerthan the time-out period. When data for a cached-timed read-requesttransaction times out, the RCM marks the data in cache memory asinvalid. Table 29 illustrates the fields for this register.

TABLE 29 Bits Access Reset Value Field Name 11:0  RW 0x0 TIMER_DIV 12 RW0x0 TIMER_EN 21:13 RW 0x0 TIMER_CUR 63:22 RO x RESERVED

The fields are defined as follows:

TIMER_DIV—This field controls the frequency at which the cached-timedread-request timer increments (The 400 MHz channel clock is divided by128 as a fixed prescaler and then again by the programmable TIMER_DTVvalue; the increment value of the cached-timed read-request timeoutcounter is 400 MHz/128/(TIMER_DIV+1).);

TIMER_EN—When this bit is one, the cached-timed read-request timer isenabled, and when this bit is zero, the cached-timed read-request timeris disabled;

TIMER_CUR—This field is a read-only field that contains the currentvalue of the cached-timed read-request timeout counter; and

RESERVED—These bits are reserved for future use.

While the present invention has been described using a variety ofembodiments, the invention is not intended to be measured thereby, butby the claims that follow. Additionally, those skilled in the art willreadily recognize a variety of additions, deletions, substitutions, andtransformations that may be made to the illustrated embodiments.Accordingly, the following claims are intended to encompass suchadditions, deletions, substitutions, and transformations to the extentthat they do not do violence to the spirit of the claims.

1. A method for conveying data between computer modules of one or moredevices, comprising: at a first computer module of a first device:sending a first transaction credit to a second computer module of asecond device in accordance with a determination that a respectivecapacity for receiving at least a portion of an incoming transactionmessage is available at the first computer module, the first transactioncredit indicating a size of the respective capacity that is available atthe first computer module; enabling a data channel at the first devicefor receiving at least a first portion of a first transaction messagefrom the second computer module of the second device, the enabling beingbased on a total amount of transaction credit currently extended to thesecond computer module by the first computer module; receiving the firstportion of the first transaction message from the second computer modulethrough the enabled data channel; and deducting a first amount oftransaction credit from the total amount of transaction credit currentlyextended to the second computer module in accordance with a respectivesize of the received first portion of the first transaction message. 2.The method of claim 1, wherein a unit of the transaction credit extendedfrom the first computer module to the second computer module correspondsto an amount of data that the data channel transmits during apredetermined number of clock cycles on the data channel.
 3. The methodof claim 2, wherein the predetermined number is one.
 4. The method ofclaim 1, wherein: the first transaction message is an incomingtransaction request from the second computer module; and the transactioncredit extended from the first computer module to the second computermodule is for receiving incoming transaction requests from the secondcomputer module at the first computer module.
 5. The method of claim 1,wherein: the first transaction message is an incoming transactionresponse from the second computer module; and the transaction creditextended from the first computer module to the second computer module isfor receiving incoming transaction responses from the second computermodule at the first computer module.
 6. The method of claim 1, whereinthe first computer module keeps track of a respective amount oftransaction credit currently extended to the second computer module foreach of a plurality of transaction types.
 7. The method of claim 6,wherein the plurality of transaction types comprises one or more typesof bus transaction requests and one or more types of bus transactionresponses.
 8. The method of claim 1, further comprising: at the firstcomputer module of the first device: incrementing the total amount oftransaction credit currently extended to the second computing device inaccordance with sending the first transaction credit.
 9. The method ofclaim 1, further comprising: at the first computer module of the firstdevice: receiving a second transaction credit from the second computermodule of the second device, the second transaction credit having beensent by the second computer module in accordance with a determinationthat a respective capacity for receiving at least a portion of anincoming transaction message has become available at the second computermodule, the second transaction credit indicating a size of therespective capacity that has become available at the second computermodule; and in accordance with receiving the second transaction credit,incrementing a total amount of transaction credit currently extendedfrom the second computer module device to the first computer module. 10.The method of claim 9, further comprising: at the first computer moduleof the first device: determining, based on the total amount oftransaction credit currently extended from the second computer module tothe first computer module, that the second computer module currently hascapacity to receive at least a first portion of a second transactionmessage from the first computer module; sending the first portion of thesecond transaction message to the second computer module in accordancewith said determination; and deducting a second amount of transactioncredit from the total amount of transaction credit currently extendedfrom the second computer module to the first computer module inaccordance with a respective size of the first portion of the secondtransaction message.
 11. A device, comprising: memory; and a firstcomputer module, wherein the first computer module is coupled to asecond computer module of a second device through a signal transportdevice having a plurality of signal links, and the first computermodule: sends a first transaction credit to the second computer moduleof the second device in accordance with a determination that arespective capacity for receiving at least a portion of an incomingtransaction message is available at the first computer module, the firsttransaction credit indicates a size of the respective capacity that isavailable at the first computer module; enables a data channel at thedevice for receiving at least a first portion of a first transactionmessage from the second computer module of the second device, theenabling being based on a total amount of transaction credit currentlyextended to the second computer module by the first computer module;receives the first portion of the first transaction message from thesecond computer module through the enabled data channel; and deducts afirst amount of transaction credit from the total amount of transactioncredit currently extended to the second computer module in accordancewith a respective size of the received first portion of the firsttransaction message.
 12. The device of claim 11, wherein sending thefirst transaction credit to the second computer module includes sendinga transaction credit signal from the first computer module to the secondcomputer module over a respective one of the plurality of signal links.13. The device of claim 11, wherein: the first computer module includesa credit generator for keeping track of the total amount of transactioncredit currently extended from the first computer module to the secondcomputer module; the credit generator increments the total amount oftransaction credit currently extended to the second computer module inaccordance with sending the first transaction credit to the secondcomputer module; and the credit generator decrements the total amount oftransaction credit currently extended to the second computer module inaccordance with receiving the first portion of the first transactionmessage from the second computer module.
 14. The device of claim 11,wherein the data channel includes a set of multiple data links, eachdata link in the set operable to receive part of the first portion ofthe first transaction message.
 15. The device of claim 11, wherein:enabling the data channel includes asserting a respective credit link ofthe plurality of signal links of the signal transport device; and thefirst computer module de-asserts the respective credit link when thetotal amount of transaction credit currently extended to the secondcomputer module has been exhausted.
 16. The device of claim 11, whereina unit of the transaction credit extended from the first computer moduleto the second computer module corresponds to an amount of data that thedata channel transmits during a predetermined number of clock cycles onthe data channel.
 17. The device of claim 11, wherein the first computermodule keeps track of a respective amount of transaction creditcurrently extended to the second computer module for each of a pluralityof transaction types.
 18. The device of claim 11, wherein: the firsttransaction message is an incoming transaction request from the secondcomputer module; and the transaction credit extended from the firstcomputer module to the second computer module is for receiving incomingtransaction requests from the second computer module at the firstcomputer module.
 19. The device of claim 11, wherein the first computermodule further: receives a second transaction credit from the secondcomputer module of the second device, the second transaction credithaving been sent by the second computer module in accordance with adetermination that a respective capacity for receiving at least aportion of an incoming transaction message has become available at thesecond computer module, the second transaction credit being indicativeof a size of the respective capacity that has become available at thesecond computer module; and sends a first portion of a secondtransaction message to the second computer module in accordance with atotal amount of transaction credit currently extended from the secondcomputer module to the first computer module.
 20. The device of claim19, wherein: the first computer module includes a credit counter forkeeping track of a total amount of transaction credit currently extendedfrom the second computer module to the first computer module; the creditgenerator increments the total amount of transaction credit currentlyextended from the second computer module to the first computer module inaccordance with receiving the second transaction credit from the secondcomputer module; and the credit generator decrements the total amount oftransaction credit currently extended from the second computer module tothe first computer module in accordance with sending the first portionof the second transaction message to the second computer module.